mirror of https://github.com/status-im/EIPs.git
Merge remote-tracking branch 'refs/remotes/origin/EIP-repo-updates'
This commit is contained in:
Souptacular
commit
eae16cfc01
|
|
@ -3,8 +3,8 @@
|
|||
Title: EIP Purpose and Guidelines
|
||||
Status: Draft
|
||||
Type: Meta
|
||||
Author: Martin Becze <mb@ethdev.com>
|
||||
Created: 2015-10-27
|
||||
Author: Martin Becze <mb@ethereum.org>, Hudson Jameson <hudson@ethereum.org>
|
||||
Created: 2015-10-27, 2016-12-07
|
||||
</pre>
|
||||
|
||||
==What is a EIP?==
|
||||
|
|
@ -13,20 +13,19 @@ EIP stands for Ethereum Improvement Proposal. A EIP is a design document providi
|
|||
|
||||
==EIP Rational==
|
||||
|
||||
We intend EIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue and for documenting the design decisions that have gone into Ethereum. Because the EIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
|
||||
We intend EIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Ethereum. Because the EIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
|
||||
|
||||
For Ethereum implementers, EIPs are a convenient way to track the progress of their implementation. Ideally each implementation maintainer would list the EIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.
|
||||
|
||||
EIPs are intend to replace the venerable etherpads which described the initial PoC (Proof of Concept) and strike a balance between ease of accessibility and trackablity.
|
||||
|
||||
==EIP Types==
|
||||
|
||||
There are three kinds of EIP:
|
||||
|
||||
* A Standard Track EIP describes any change that affects most or all Ethereum implementations, such as a change to the [https://github.com/ethereum/yellowpaper Yellow Paper], the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories.
|
||||
** Consensus - Once PoS has been established it is expected that PoS protocol will have a separate specification.
|
||||
** Networking - Currently Networking discussion tracks in the [https://github.com/ethereum/devp2p devp2p repository].
|
||||
There are three types of EIP:
|
||||
|
||||
* A Standard Track EIP describes any change that affects most or all Ethereum implementations, such as a change to the the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories.
|
||||
** Core - improvements requiring a consensus fork (e.g. [https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5.md EIP5], [https://github.com/ethereum/EIPs/issues/28 EIP101]), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, [https://github.com/ethereum/EIPs/issues/90 EIP90], and the miner/node strategy changes 2, 3, and 4 of [https://github.com/ethereum/EIPs/issues/86#issue-145324865 EIP86]).
|
||||
** Networking - includes improvements around [https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol devp2p] ([https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8.md EIP8]) and [https://github.com/ethereum/wiki/wiki/Light-client-protocol Light Ethereum Subprotocol], as well as proposed improvements to network protocol specifications of [https://gist.github.com/gluk256/4654922ca45eb9d0846d941d7ca326f4 whisper] and [https://github.com/ethereum/go-ethereum/pull/2959 swarm].
|
||||
** Interface - includes improvements around client [https://github.com/ethereum/wiki/wiki/JSON-RPC API/RPC] specifications and standards, and also certain language-level standards like method names ([https://github.com/ethereum/EIPs/issues/59 EIP59], [https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6.md EIP6]) and [https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI contract ABIs]. The label “interface” aligns with the [https://github.com/ethereum/interfaces interfaces repo] and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.
|
||||
** ERC - application-level standards and conventions, including contract standards such as token standards ([https://github.com/ethereum/EIPs/issues/20 ERC20]), name registries ([https://github.com/ethereum/EIPs/issues/26 ERC26], [https://github.com/ethereum/EIPs/issues/137 ERC137]), URI schemes ([https://github.com/ethereum/EIPs/issues/67 ERC67]), library/package formats ([https://github.com/ethereum/EIPs/issues/82 EIP82]), and wallet formats ([https://github.com/ethereum/EIPs/issues/75 EIP75], [https://github.com/ethereum/EIPs/issues/85 EIP85]).
|
||||
* An Informational EIP describes a Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementors are free to ignore Informational EIPs or follow their advice.
|
||||
* A Meta EIP describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.
|
||||
|
||||
|
|
@ -34,25 +33,23 @@ There are three kinds of EIP:
|
|||
|
||||
The EIP repository Collaborators change the EIPs status. Please send all EIP-related email to the EIP Collaborators, which is listed under EIP Editors below. Also see EIP Editor Responsibilities & Workflow.
|
||||
|
||||
The EIP process begins with a new idea for Ethereum. It is highly recommended that a single EIP contain a single key proposal or new idea. Small enhancements or patches that don't affect consensus often don't need a EIP and can be injected into the Ethereum development workflow with a patch submission to the corresponding Ethereum issue tracker. The more focused the EIP, the more successful it tends to be. The EIP editor reserves the right to reject EIP proposals if they appear too unfocused or too broad. If in doubt, split your EIP into several well-focused ones.
|
||||
The EIP process begins with a new idea for Ethereum. It is highly recommended that a single EIP contain a single key proposal or new idea. Small enhancements or patches often don't need an EIP and can be injected into the Ethereum development workflow with a patch submission to the corresponding Ethereum issue tracker. The more focused the EIP, the more successful it tends to be. The EIP editor reserves the right to reject EIP proposals if they appear too unfocused or too broad. If in doubt, split your EIP into several well-focused ones.
|
||||
|
||||
Each EIP must have a champion -- someone who writes the EIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The EIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is EIP-able. Posting to the the [https://forum.ethereum.org/categories/protocol-and-client-discussion Protocol Discussion] forum or opening an [https://github.com/ethereum/EIP/issues Issue] is the best way to go about this.
|
||||
Each EIP must have a champion -- someone who writes the EIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea.
|
||||
|
||||
Vetting an idea publicly before going as far as writing a EIP is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used.
|
||||
Vetting an idea publicly before going as far as writing a EIP is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used. Examples of appropriate public forums to gauge interest around your EIP include [https://www.reddit.com/r/ethereum/ the Ethereum subreddit] and [https://gitter.im/ethereum/ one of the Ethereum Gitter chat rooms].
|
||||
|
||||
Once the champion has asked the Ethereum community as to whether an idea has any chance of acceptance, a draft EIP should be presented as a Pull Request. This gives the author a chance to flesh out the draft EIP to make properly formatted, of high quality, and to address initial concerns about the proposal.
|
||||
Once the champion has asked the Ethereum community whether an idea has any chance of acceptance a draft EIP should be presented as a [https://github.com/ethereum/EIPs/pulls pull request]. This gives the author a chance to coninuously edit the draft EIP for proper formatting and quality. It also allows for public comment and the author of the EIP to address concerns about the proposal. Members of the community can publically comment on the draft EIP through the pull request.
|
||||
|
||||
If the EIP collaborators approves, the EIP editor will assign the EIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the git repository. The EIP editor will not unreasonably deny an EIP. Reasons for denying EIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Ethereum philosophy.
|
||||
|
||||
The EIP author may update the Draft as necessary in the git repository. Updates to drafts may also be submitted by the author as pull requests.
|
||||
|
||||
Standards Track EIPs consist of three parts, a design document, implementation and finally if warranted an update to the [https://github.com/ethereum/yellowpaper formal specification]. The EIP should be reviewed and accepted before an implementation is begun, unless an implementation will aid people in studying the EIP. Standards Track EIPs must be implemented in at least two viable Ethereum clients before it can be considered Final.
|
||||
Standards Track EIPs consist of three parts, a design document, implementation, and finally if warranted an update to the [https://github.com/ethereum/yellowpaper formal specification]. The EIP should be reviewed and accepted before an implementation is begun, unless an implementation will aid people in studying the EIP. Standards Track EIPs must be implemented in at least two viable Ethereum clients before it can be considered Final.
|
||||
|
||||
EIP authors are responsible for collecting community feedback on a EIP before submitting it for review. However, wherever possible, long open-ended discussions should be avoided. Strategies to keep the discussions efficient include: having the EIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. EIP authors should use their discretion here.
|
||||
|
||||
For a EIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
|
||||
|
||||
Once a EIP has been accepted, the implementations must be completed. When the implementation is complete in at least two viable clients and accepted by the community, the status will be changed to "Final". An update to the [https://github.com/ethereum/yellowpaper formal specification] should accompany the "Final" status change.
|
||||
Once a EIP has been accepted, the implementations must be completed. When the implementation is complete and accepted by the community, the status will be changed to "Final".
|
||||
|
||||
A EIP can also be assigned status "Deferred". The EIP author or editor can assign the EIP this status when no progress is being made on the EIP. Once a EIP is deferred, the EIP editor can re-assign it to draft status.
|
||||
|
||||
|
|
@ -86,45 +83,42 @@ Each EIP should have the following parts:
|
|||
|
||||
* Implementations -- The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.
|
||||
|
||||
* Simple Summary -- "If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.
|
||||
|
||||
==EIP Formats and Templates==
|
||||
|
||||
EIPs should be written in mediawiki or markdown format. Image files should be included in a subdirectory for that EIP.
|
||||
EIPs should be written in [https://en.wikipedia.org/wiki/Help:Cheatsheet mediawiki] or [https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet markdown] format. Image files should be included in a subdirectory for that EIP.
|
||||
|
||||
==EIP Header Preamble==
|
||||
|
||||
Each EIP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required.
|
||||
|
||||
<pre>
|
||||
EIP: <EIP number>
|
||||
EIP: <EIP number> (this is determined by the EIP editor)
|
||||
Title: <EIP title>
|
||||
Author: <list of authors' real names and optionally, email address>
|
||||
* Discussions-To: <email address>
|
||||
Status: <Draft | Active | Accepted | Deferred | Rejected |
|
||||
Withdrawn | Final | Superseded>
|
||||
Type: <Standards Track | Informational | Process>
|
||||
* Discussions-To: <email address>
|
||||
Status: <Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded>
|
||||
Type: <Standards Track (Core, Networking, Interface, ERC) | Informational | Process>
|
||||
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
|
||||
* Replaces: <EIP number>
|
||||
* Superseded-By: <EIP number>
|
||||
* Resolution: <url>
|
||||
</pre>
|
||||
* Replaces: <EIP number>
|
||||
* Superseded-By: <EIP number>
|
||||
* Resolution: <url>
|
||||
|
||||
The Author header lists the names, and optionally the email addresses of all the authors/owners of the EIP. The format of the Author header value must be
|
||||
|
||||
Random J. User <address@dom.ain>
|
||||
Random J. User <address@dom.ain>
|
||||
|
||||
if the email address is included, and just
|
||||
if the email address is included, and
|
||||
|
||||
Random J. User
|
||||
Random J. User
|
||||
|
||||
if the address is not given.
|
||||
|
||||
If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.
|
||||
if the email address is not given.
|
||||
|
||||
Note: The Resolution header is required for Standards Track EIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the EIP is made.
|
||||
|
||||
While a EIP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the EIP is being discussed. No Discussions-To header is necessary if the EIP is being discussed privately with the author.
|
||||
|
||||
The Type header specifies the type of EIP: Standards Track, Informational, or Process.
|
||||
The Type header specifies the type of EIP: Standards Track, Meta, or Informational. If the track is Standards please include the subcategory (core, networking, interface, or ERC).
|
||||
|
||||
The Created header records the date that the EIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.
|
||||
|
||||
|
|
@ -146,6 +140,7 @@ If you are interested in assuming ownership of a EIP, send a message asking to t
|
|||
|
||||
The current EIP editors are
|
||||
* Martin Becze
|
||||
* Hudson Jameson
|
||||
|
||||
==EIP Editor Responsibilities & Workflow==
|
||||
|
||||
|
|
@ -174,3 +169,5 @@ The editors don't pass judgment on EIPs. We merely do the administrative & edito
|
|||
==History==
|
||||
|
||||
This document was derived heavily from [https://github.com/bitcoin/bips Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [https://www.python.org/dev/peps/ Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Improvement Process, and should not be bothered with technical questions specific to Ethereum or the EIP. Please direct all comments to the EIP editors.
|
||||
|
||||
December 7, 2016: EIP 1 has been improved and will be placed as a PR. Hudson Jameson is now the EIP editor.
|
||||
|
|
|
|||
Loading…
Reference in New Issue