Skip to main content

Ethereum Improvement Proposal

· 3 min read
0xMacintosh

Ethereum Improvement Proposals (EIPs) define standards for the Ethereum blockchain, including core protocol specifications, client APIs, and contract standards. EIPs can also propose changes to the Ethereum ecosystem that are not directly related to the technical specifications.

EIP-1: EIP Purpose and Guidelines

EIP Structure​

Preamble​

The preamble includes the EIP number, title, author, and contributors. It also includes a summary of the proposal and the motivation behind it.

https://eips.ethereum.org/EIPS/eip-1#eip-header-preamble

EIP Preamble

Abstract​

A technical description of the proposal, including the problem it solves and the benefits it provides. It should be clear and concise.

Motivation​

A detailed explanation of the problem the proposal solves and why it is important to solve it. It should provide context and background information. This section should explain why the existing protocol specification is inadequate to address the problem that the EIP solves. If the motivation is evident, this section may be omitted.

Specification​

The technical specification should describe the syntax and semantics of any new feature. It should include any necessary changes to the Ethereum protocol, API, or contract standards. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (besu, erigon, ethereumjs, go-ethereum, nethermind, or others).

Rationale​

The rationale explains the reasoning behind the proposal and discusses the benefits and drawbacks of the proposed changes. It should also address any potential issues and provide reasoning for the proposed changes. Additionally, the rationale should discuss any alternate designs that were considered and related work, such as how the feature is supported in other languages. This section should also address any important objections or concerns raised during discussion around the EIP.

For example, we can use the following format to explain design choices,

ERC-6220​

EIP Ratinoale

Backwards Compatibility​

A discussion of how the proposal affects backwards compatibility. It should explain any changes that may break existing contracts or applications.

Test Cases​

Examples of how the proposal can be implemented and tested. It should include test scenarios and expected outcomes.

Reference Implementation​

An optional section that contains a reference or example implementation that people can use to assist in understanding or implementing this specification. This section should include any code or links to code repositories that implement the proposal. It should also provide clear instructions on how to use the implementation and any dependencies that it has. If there are multiple reference implementations, they should be listed separately.

Security Considerations​

A discussion of any security risks associated with the proposal and how they can be mitigated.

All EIPs must be in the public domain. The copyright waiver MUST link to the license file and use the following wording: Copyright and related rights waived via CC0.

EIPs are an important part of the Ethereum ecosystem and provide a standardized way to propose, discuss, and implement changes. By following this structure, EIP authors can ensure their proposals are clear, concise, and well-documented.


EIP Process​

The EIP process is designed to provide a standardized way to propose, discuss, and implement changes to the Ethereum ecosystem.

Idea - An idea that is pre-draft. This is not tracked within the EIP Repository.

Draft - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.

Review - An EIP Author marks an EIP as ready for and requesting Peer Review.

Last Call - This is the final review window for an EIP before moving to Final. An EIP editor will assign Last Call status and set a review end date (last-call-deadline), typically 14 days later.

If this period results in necessary normative changes it will revert the EIP to Review.

Final - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.

A PR moving an EIP from Last Call to Final SHOULD contain no changes other than the status update. Any content or editorial proposed change SHOULD be separate from this status-updating PR and committed prior to it.

Stagnant - Any EIP in Draft or Review or Last Call if inactive for a period of 6 months or greater is moved to Stagnant. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to Draft or it’s earlier status. If not resurrected, a proposal may stay forever in this status.

EIP Authors are notified of any algorithmic change to the status of their EIP

Withdrawn - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.

Living - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.

By following this process, EIP authors can ensure that their proposals are well-vetted and have the support of the community.

EIP Process