Ethereum Governance Model

Owned by Former user (Deleted)
Last updated: Jun 26, 2019
5 min read

Ethereum Improvement Proposals (EIP) are design documents providing information or describing a new feature for Ethereum, its processes, or its environment to the Ethereum community. Their purpose is to serve as the primary mechanism for proposing new features, collecting community technical input on an issue, and for documenting the design decisions that have gone into Ethereum.

There appear to have been around ~2050 EIP’s since Ethereum’s conception.

There are three types of EIP’s, all of which serve a different purpose to the community:

Standard Track EIP

These involve any change that affects most or all of the Ethereum implementations. This includes any changes in network protocol, blockchain transaction validity rules, etc. Standard EIP’s fall into one of four categories: consensus, networking, API/RPC, and applications. In addition, they consist of three parts: a design document, implementation, and if warranted, an update to the formal specification. There are four types of Standard Track EIP’s:

  • Core: involves improvements requiring a consensus fork as well as changes that involve ‘core dev’ decisions
  • Networking: includes improvements around devp2 and Light Ethereum Subprotocol as well as network protocols involving whisper and swarm.
  • Interface: involves improvements around client API/RPC specification standards.
  • ERC: involves application-level standards and conventions, including contract standards such as token standards, name registries, and wallet formats.

Meta EIP

Meta EIP’s involve describing a process surrounding Ethereum or proposing a change to a process. It is similar to a Standard EIP, except it applies to issues outside of protocol. These propose an implementation, but not to the code itself. They generally require more of a community based decision to change some form of the decision making process.

Informational EIP

Informational EIP’s describe an Ethereum design issue, but do not propose a new feature. They do not require consensus and it is at the liberty of the user to decide whether or not to implement the change.

EIP Requirements:

  • Preamble: A short descriptive title, author details, and the EIP number.
  • Summary: A simple, brief description of the EIP.
  • Abstract: A short description of the technical specifications of the EIP.
  • Motivation: These are critical for EIP’s seeking to change the Ethereum protocol. It is a clear explanation of why the existing protocol is inadequate to solve the problem the current EIP seeks to solve.
  • Specification: Describes the syntax of the new feature. It should be detailed enough to allow competing and interoperable implementations of the current Ethereum platforms.
  • Rationale: Explains why particular design decisions were made. It should consider alternate designs and show compatibility in different languages. It must also show consensus within the community and discuss important concerns.
  • Backwards Compatibility: All EIP’s with backwards incompatibility must describe these incompatibilities and their severity. The author must explain how they intend to deal with these incompatibilities.
  • Test Cases: These are mandatory for EIP’s affecting consensus changes.
  • Implementations: This must be completed before any EIP is given status ‘Final’, but does not need to be completed before the EIP is merged as a draft.
  • Copyright waiver: All EIP’s must be in the public domain.

The EIP format design and implementation is as follows:

Work in Progress (WIP)

An EIP qualifies as a Work in Progress (WIP) when the author drafts a pull request.

  • Accepted: The draft is concise, states the problem, their solution, the backwards compatibility, and is not a duplicate to other EIP’s.
  • Denied: too unfocused, too broad, duplication effort, technically unsound.

If accepted, the EIP Editor will assign the EIP a number and merge the authors pull request.

Draft

After the first draft has been accepted and merged, the author may submit follow-up pull requests to further changes until he or she believes the EIP is materially sound. The draft must be implemented in order to move to the next step.

  • Accepted: If there are no more material changes to be made to the code, the EIP will proceed to ‘Last Call’.
  • Denied: IF material changes are still expected to be made.

If accepted, the EIP editor will assign a ‘Last Call’ status and set a review date.

Last Call

During ‘Last Call’ the EIP will be listed on the Ethereum website.

  • Accepted (CORE EIP ONLY): if there are no technical or material issues it will move to ‘Accepted’.
  • Accepted (Not CORE EIP): if there are no technical or material issues it will move to ‘Final’.
  • Denied: a ‘Last Call’ which results in material changes or substantial unaddressed technical issues will cause the EIP to revert back to the previous step, ‘Draft’.

If accepted, Core EIP’s will move to ‘Accepted’ and all other EIP’s will move to ‘Final’.

Accepted (CORE EIP ONLY)

Core EIP’s move to the hands of the Ethereum Client Developers.

  • Accepted: Must be implemented in at least three viable Ethereum clients before it can be considered final. When implementation is completed and adopted by the community, the status will change to ‘Final’.

Final

This EIP represents the current implementations.

Other statuses during design and implementation

  • Deferred: Core EIP’s that have been put off for a hard fork in the future.
  • Rejected: An EIP that is fundamentally broken or a Core EIP which was rejected by the Core developers and will not be implemented.
  • Active: Similar to final, but denotes an EIP which may be updated without changing its EIP number.
  • Superseded: An EIP which was previously final but is no longer considered state-of-the-art. Another EIP will be in final and reference the Superseded one.

Current EIP Editors

  1. Nick Johnson
  2. Casey Detrio
  3. Hudson Jameson
  4. Vitalik Buterin
  5. Nick Savers
  6. Martin Becze
  7. Greg Colvin
  8. Alex Beregszaszi

The DAO Fork & Ethereum Classic:

The Decentralized Autonomous Organization (DAO) was a digital venture-capital fund instantiated on the Ethereum blockchain. It carried a decentralized, stateless business model for commercial and non-profit businesses. In May, 2016 DAO was crowdfunded via token sale, totaling over US$150 million from more than 11,000 investors. During this time a series of vulnerabilities, including recursive calls among others, were set forth by the Ethereum community, who urged that these issues needed to be addressed by the DAO team. In June, DAO was subject to an attack, using a combination of vulnerabilities, which managed to siphon 1/3 of the total token fund, totaling approximately US$50 million.

As a result, Ethereum hard forked. Half of the Ethereum community called for the Ether to be re-appropriated. As a result, the Ethereum network moved the funds in the DAO to a recovery address where it could be exchanged back to Ethereum by its original owners.

Those on the other side of the fork called the attack a valid but unethical move. This chain is known as Ethereum Classic.