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.
Three types of EIP
Standard Track EIP
Core
Networking
Interface
ERC - application-level standards and conventions
Informational EIP - design issue, or provides general guidelines or information to the Ethereum community
Meta EIP - procedures, guidelines, changes to the decision-making process, and changes to the tools
EIP Work Flow
The EIP process begins with a new idea for Ethereum.
Each EIP must have a champion
A draft EIP should be presented as a pull request
Standards Track EIPs consist of three parts, a design document, implementation, and finally if warranted an update to the formal specification.
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 an 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”.
What belongs in a successful EIP?
Preamble
Simple Summary
Abstract
Motivation
Specification
Rationale
Backwards Compatibility
Test Cases
Implementations
Copyright Waiver
EIP Editor Responsibilities and Workflow
For each new EIP that comes in
Read the EIP to check if it is ready: sound and complete.
Edit the EIP for language
Once ready for the repository:
Assign an EIP number
Accept the corresponding pull request
List the EIP in README.md
The editors don’t pass judgment on EIPs. We merely do the administrative & editorial part.
I think a lot can be learned from the IETF in terms of process, particularly from the notion of “rough consensus”. On Consensus and Humming in the IETF by Pete Resnick (which you have referenced) shows how seriously they take effective decision-making.
Greg has been championing the idea of learning from the IETF and other standards bodies for a long time now, and we should. Definitely point to any other organizations (even corporate as in Zappos) that we can learn from.
Nick Johnson @Arachnid recently posted a comment on EIP-898 that describes current operating process really well. His description illustrates how the de-facto process is different from the process outlined in EIP-1).
Here’s my understanding of the current process, based on EIP 1 and experience:
Someone submits a draft EIP as a pull request
Interested participants debate the proposal until consensus on the contents of the draft have been reached.
An EIP editor merges the PR as a draft
Someone submits a PR to update the draft; repeat from step 2.
Once the EIP is ‘mature’, if it modifies the protocol it’s discussed at an All Core Devs meeting. If the participants agree it’s a good idea, they implement it in their specific clients, and the EIP moves to ‘accepted’.
Once implemented, if the EIP modifies consensus, it’s added to a scheduled hard fork.
The hard fork and its contents are announced, and users have the opportunity to determine if they accept the hard fork or reject it.
The hard fork block is reached, and people upgrade, or don’t.
I’ll start. Each item in the above list (with the exception of item 2) has a pretty clear group of participants: (1) someone…, (3) an EIP editor, (4) someone…, (5) core devs, (6) core devs (implicit), (7) miners, (8) miners. Item (2) has ‘interested participants’ which is ill-defined.
The primary concern, if I may try to voice it, is that the portion of the ‘interested participants’ that are not ‘core devs’ and who disagree with the decisions made by the ‘core devs’ (or even disagree that ‘consensus’ has been reached) have a lesser say in what happens.
I’m not suggesting any solutions, only pointing to the crux of issue. The other steps seem pretty clear to me.
I think the problem lies in #2 first and foremost. Debating until consensus is reached. It’s not a great model for a few reasons, 1) no explicit time constraints on debate, and 2) no explicit definition of consensus.
Also #5 “if the participants agree…” this implies that after consensus has been reached and the EIP matured, the Core devs still have a layer of approval for go/no go. This marginalizes the participants in the initial consensus process described in #2 if that process includes parties outside the Core devs. There needs to be clarification that this agreement/veto only occurs based on technical grounds (e.g. we merged it, we tested it, it doesn’t work we can’t do it). That is the only condition in my mind where the Core devs should retain an ultimate go/no go vote after the initial public debate / social consensus regarding the EIP was reached.
In matters of pure technical viability, Core devs should retain that final say post testing.
I’d imagine a conditional workflow for the EIP consensus and I can draw something up. I think we want this to be as lean and efficient a process as possible but also, as inclusive as possible.
7 and 8 are not ‘miners’, they are ‘economic participants’. Miners don’t decide which hard fork gets adopted, they follow the money. They can mine whatever fork they want, but since reorgs don’t happen across hard forks, that has no impact on which side gets accepted by the community.
Ultimately, this will always be the case: you cannot force the implementers of a piece of software to write or merge changes they do not agree with. If you want to force a change against the wishes of the maintainers, you will have to fork the code and do it yourself.
Yes, but that is meant to be debated in #2, not number five. If the general consensus is to move forward with an EIP after the open debate (which the devs are a part of), then by vetoing or refusing to merge the developers have exacted their own will upon the state of the blockchain, which needs to be effectively reduced to near zero. Not only to protect the governance process and keep it fair, but also to protect the EIP editor should issues of legality from action / inaction arise (as Yoichi pondered).
Actually I’m wondering if the open debate / initial social consensus guage should be occurring before an EIP is even submitted. Or some sort of agreement on what classes of changes are even allowable for EIP submission (thin line here since that requires a definition for classes of changes which itself would require consensus). Thinking behind that, though, is if anything can be submitted as an EIP, the community and devs can be inundated with consensus votes, so much to the point where participation will be affected due to the sheer volume of proposals on the table at any given time.
Disagree. Engineers who work on clients can comment during #2, but just because there’s technical consensus on the contents of an EIP doesn’t mean that they are happy to implement it in their clients. There’s a number of reasons they might object to implementing the EIP even if the specification is stable.
In my mind, the role of EIP editors should be as straightforward as possible, which means assessing as objectively as possible whether a standard is stable; this doesn’t imply assessing an EIP’s viability.
It’s very difficult to debate the merits of something that isn’t sufficiently specified.
Again, trying to build in restrictions on what can be standardised misses the point. There’s nothing that says that hard fork changes have to come from EIPs; if we make the EIP process harder to navigate, people will just go elsewhere. EIPs are an input to the hard fork process, not part of the process itself.
So why not do away with any sort of social debate if the developers are ultimately the gate keepers anyway?
I also don’t get what you’re saying up top about there being technical consensus but clients not wanting to implement. If it reaches the defined consensus point for acceptance, and they disagree with it, they’re free to fork. We can’t let EIPs just die because one client or one subset of interest groups disagrees, that defeats the entire point of consensus, no?
At the end of the day the devs need to either honor the consensus or we abandon the thought of a greater community inclusive consensus, because devs will ultimately be acting as gatekeepers anyway, which in my opinion, defeats the purpose of trying to make any sort of decentralized governance process work.
Because devs won’t implement something if they’re sure nobody wants it - and they’ll be more inclined to implement something if there’s clear signs it’ll be useful to people. Feedback is good.
Suppose there’s consensus on an EIP that would slow down a client implementation by a factor of 10 if implemented. Clearly, client implementers would reject this.
I think you’re being ambiguous about what you mean by ‘consensus’.
In the EIP writing process, it’s agreement on what the standard should contain.
When it comes to the chain, ‘consensus’ is what clients preserve.
When it comes to adopting or not adopting changes, ‘consensus’ is something the community agrees on.
Ultimately, there’s no way to force client implementers to implement something that they don’t think is a good idea. No amount of legislating can get around that.
I think I see what you’re saying, regarding the clients not updating/implementing, effectively refusing the change. I guess I was talking about before it even comes to that. The “social consensus” between the community and the devs (versus technical or on chain). Getting from the open debate about a change to the standardization in an EIP and ultimately merging and implementing. Right now I feel like there’s a lack of clarity on what should or shouldn’t be submitted as an EIP, and where the decision making process lies in that regard.
I can abandon using the confusing terminology and just refer to it as the initial public debate and path forward versus “social consensus”
Really the way the governance process works is a series of vetos. None of the vetos stop the process from moving forward, but a group exercising their veto power makes it significantly harder for the process to move forward for others.
First veto is the EIP editors, who can choose to not merge an EIP into draft.
Second veto is the Core Devs group, who can choose to recommend against a change.
Third veto is the client dev teams, who can choose not to implement a change.
Fourth veto are economic participants, who can choose not to use a client that implements a change.
The process can be skipped/bypassed by anyone. As a user, I can fork a client, author a change, and then run a node containing that change I will have successfully hard forked with the change I desire, but it is unlikely that anyone would join me on my chain in this case. Thus, the veto powers at each step are weak at best.
The system has inertia as well. If something makes it all the way to implemented in clients, it has a lot of inertia and it is actually reasonably difficult to get the community to not move forward with that change. Similarly, if the Core Devs call results in agreement on a change, it would be hard for a single client to exercise their veto power (but they can certainly try).
I’m personally a fan of this mechanism for client development and protocol improvements. I think democracy and voting in general is a terrible process because the vast majority of voters are largely uninformed and vote with their heart, not their head (I have personally done this in the past as well, it is human nature). This process allows people who have spent a lot of time thinking about an issue the least amount of inertia pushing against them and those who have spent less time more inertia to fight against.
I disagree, client developers can choose. So I suggest that you say, “Once an EIP has been accepted, client developers choose whether to adopt them or not. If the EIP is adopted in implementations, then the community has to choose whether or not to upgrade their clients. Once the majority have updated their clients then the EIP can be considered to be adopted by the community, and the status can be changed to final.” However, an issue with this last point is that you would need to somehow track the percentage of upgrades to the latest implementation.
Note that not all of these are always applicable, e.g. Backwards Compatibility, Test Cases, and Implementations. I have wrote a few EIPs and I have just left the template for these sections or commented them out.
https://www.rfc-editor.org/rfc/rfc7282.txt is worth reading. It raises an interesting governance process that could be applied beyond technical systems: eliminating objections or discarding a proposal if the objection can’t be technically fixed. However you would still need some kind of signalling/voting to replace humming (which starts the process of consensus), because humming can’t be done at scale and needs most stakeholders/participants to be involved in person, but like rough consensus, this signalling would be the beginning of the process. When I first heard about rough consensus I was skeptical, but this article gives a reasonable exposition of why it is useful, and better than just voting.
