Formalize EIP acceptance protocol

[sfultong]

in order to avoid situations where The Ethereum Foundation works against the will of the community, the community needs an explicit voice capable of vetoing implementation of EIPs.

I think the least bad implementation of this would involve a coin vote, although I'm open to other suggestions.

At the very least, if the community is not to have an explicit voice, more clarity and transparency (is EIP acceptance determined by a vote internal to The EF?) would improve the relationship between The EF and the community.

As it's currently not clear how EIPs are accepted, people against certain EIPs (E.G 867) feel the need to voice their disagreement in PR comments. If there were a clear difference between accepting an EIP for consideration and accepting an EIP for approval, PR comments could be better limited to constructive criticism and streamline the process.

[MicahZoltu]

@sfultong Which part of EIP-1 do you find unclear? Currently, the governance system states that the users have the final say by choosing whether or not to upgrade their clients.

[Arachnid]

Here's my understanding of the current process, based on EIP 1 and experience:

1. Someone submits a draft EIP as a pull request
2. Interested participants debate the proposal until consensus on the contents of the draft have been reached.
3. An EIP editor merges the PR as a draft
4. Someone submits a PR to update the draft; repeat from step 2.
5. 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'.
6. Once implemented, if the EIP modifies consensus, it's added to a scheduled hard fork.
7. The hard fork and its contents are announced, and users have the opportunity to determine if they accept the hard fork or reject it.
8. The hard fork block is reached, and people upgrade, or don't.

A couple of really important notes here. First, the part at which the general userbase has input is on deciding to accept or reject a proposed change by way of hard fork. This is the network's ultimate governance method, and employs economic consensus to determine which 'side' 'wins'. As a result, individual end users don't need to 'vote' on draft EIPs, and thus we don't need a formalised process for taking community consensus at that point of the process. Further, the presence of this ultimate check discourages the implementation of a change that everyone knows will be unpopular.

Second, 'consensus' in the EIP process does not mean "nobody disagrees"; it means that all technical and editorial concerns that have been raised have been adequately addressed. RFC 7282 is an example of how the IETF handles this, and the sort of process we aspire to. In this context, voting can be harmful, as it gives the impression that decisions are taken by majority rule; on the contrary, one single participant expressing a critical flaw should be enough to torpedo a proposal, and a hundred people with irrelevant objections should not.

Personally, I think this is a good process (at least, if functioning as designed); it ensures that standards get written to the highest technical standard we can achieve, and it ensures they don't get adopted unless the community agrees (that last bit is baked into the operation of a consensus system - we couldn't change it even if we wanted).

Finally, one last note: The EF does not run the EIP process - EIP editors are volunteers and don't all work for the EF. Nor does the EF have the final say at all core devs meetings.

[swaldman]

@Arachnid

A few comments:

1. I think quite legitimately, many members of the community would perceive approval of an EIP at an All Core Devs meeting and its marking as 'accepted' as being quite strong "coordination flags" (in @vbuterin's terminology). Yes, in a formal sense, neither core devs nor the Ethereum Foundation can insist that nodes upgrade, but in practical terms dissenting once such strong coordination flags have been set means one very likely has already lost a great deal. Either ones choice will leave his or her node uselessly out of consensus, or the node operators will be genuinely divided and the community will bifurcate a la Ethereum Classic. I don't think it at all unreasonable that, at least for some matters, the broader community wants some more defined role in social consensus formation prior to what would amount to a long-shot boycott.

2. Regarding

   RFC 7282 is an example of how the IETF handles this, and the sort of process we aspire to. In this context, voting can be harmful, as it gives the impression that decisions are taken by majority rule; on the contrary, one single participant expressing a critical flaw should be enough to torpedo a proposal, and a hundred people with irrelevant objections should not.

   This makes much more sense for matters that might be understood as technical than for matters that might be understood as political. Unfortunately, the distinction between those categories blur, in general but especially in blockchain systems, where technical changes create economic winners and losers quite directly.

   Although it will never be possible to distinguish the technical and political perfectly, like Potter Stewart's dictum about pornography, we kind of "know it when we see it" if some proposal is in fact political. I think the EIP process as you describe it may be adequate for technical questions, but it is not adequate for more contentious and political questions. When EIP commentary devolves to what are essentially political debates, there should be some other process besides or in addition to the expertise-focused process that you describe.

---

I say all this, by the way, without prejudging contentious questions like when and whether it is appropriate to unfreeze lost assets or reverse "bad" transactions. I supported the DAO fork and would support, under some circumstances and with clear justification for why it is to the benefit of the entire community, other proposals that restore lost assets or undo malicious actions. Nevertheless, EIP 867 struck me as entirely inappropriate, a way of making an ostensibly technical change for the clear purpose of greasing the skids for a particular resolution of contentious political questions. The process for overriding pre-agreed "automatic consensus" with exceptional "manual consensus" (@gavofyork's terms) ought not to be streamlined and easy. It should require very extraordinary social consensus, and it is a virtue, not a vice, that the process for executing such changes not be ordinary or routine. But that is a social and political claim. No matter how beautifully and efficiently, as a technical matter, support for "state change objects" could be designed into common node implementations, this political point would stand. And the EIP process, at least as I understand it at present to be constituted, is poorly suited to address this kind of point.

---

It is very important to me to end by emphasizing that I don't think anyone is acting in bad faith here, that I sympathize a very great deal with people who lost not-so-small fortunes by adopting software produced by extremely reputable people within the Ethereum community, and that I oppose the self-righteousness and bitter ideological certainty that often suffuse blockchain debates when they do become political. I especially sympathize with the EIP editors, who are trying, actually, to be editors but find themselves in appearance or in actuality thrust into very different roles. If we as a community find ways to move past a caveat emptor ethos without undermining the predictability and consistency, and therefore the legitimacy, and therefore the value, of a blockchain system, I'd be excited to do that. But whether and how we do so is not primarily a technical matter, and I am not sure the EIP process is well suited to shepherding so broad an evolution.

[Arachnid]

@swaldman Well put. I don't agree with everything you say, but I think you're broadly right.

The question, though, is whether there's a way to reliably assess community consent on a proposal, without making the standardisation process a political quagmire? I'm strongly of the opinion that good standards are not written by voting, and that approving a standard (independent of implementing it or deploying it) should not require approval from the entire community.

Further, the final 'supreme court' is always going to be the economic consensus on which chain has value. Whether some form of pre-fork governance can be established that adequately aligns with that is a difficult question.

[sfultong]

@MicahZoltu

Well, one thing I'd like is some clarification of what "not in keeping with the Ethereum philosophy" means. Is the Ethereum philosophy solely the discretion of the EIP editors?

If an EIP moves to the "Final" state, does that mean it's officially part of Ethereum and users can take it or leave it, or can users somehow prevent an EIP from becoming part of the standard simply by not using supporting clients?

Ultimately, what is Ethereum? When the next contentious hard fork happens, which branch gets the Ethereum name? Is that solely determined by The Ethereum Foundation?

I think that having a formal protocol for resolving contentious hard forks ahead of time will limit damage to the community.

[sfultong]

@Arachnid Thanks for describing the process in detail.

I'm not sure I'd want all changes to Ethereum driven by majority vote, but I think if there's overwhelming community opposition to an EIP, it should be rejected before being scheduled in a hard fork. I think most people would agree to that; the tricky part would be to define "overwhelming".

[jpitts]

Excellent description of the process as it currently works, @Arachnid.

The AllCoreDevs meeting is a good forum in which to discuss the technical merits of an EIP, but may not be the best forum in which to discuss the moral/ethical/legal/philosophical implications of decisions. Those attending AllCoreDevs are mostly engineers after all, not experts in M/E/L/P. Still, I do appreciate the efforts made at each meeting to reflect on these matters and to attempt to channel community sentiment (especially when the decision is controversial).

The reality here is that groups in the community need to organize if their voices are to be heard by those deciding to accept an EIP, much less have their voices incorporated into the approval step of the EIP workflow.

The Fellowship is being organized to improve communications and decision-making processes for Ethereum engineers, perhaps a similar effort can be organized in the community for moral/ethical/legal/philosophical work.

An institution can emerge to develop "Ethereum philosophy", discuss EIPs in terms of the M/E/L/P implications, reach out to the community for feedback, and even come to consensus to make recommendations to the wider community, AllCoreDevs, and implementers.

[jpitts]

@sfultong, there clearly there needs to be an improvement in how the process incorporates M/E/L/P objections, but as I mentioned in the above post, I don't think changes can happen in the EIP process until the stakeholders in the community better define themselves and clarify their views.

But your concern that the EIP process is biased is a very important one, and this can partly be addressed by more clarity and summaries/analyses of the process as it currently works. The EIP workflow and even decision-making in general (!) seem to be widely misunderstood in the Ethereum community, and we must work to improve this.

There is a very high priority to understanding and improving governance. Every rocket has a guidance system; how is ours?

To scale the process (given the level of technology adoption we are now looking at), I believe that the community must adopt principles and practices similar to those outlined in the Fellowship invitation.

[sfultong]

@jpitts
I'm talking about one well-defined and measurable category of stakeholders: everyone who owns eth. Their views can be clarified through a carbon votes on whether or not EIPs should be implemented in clients. if a carbon vote is 80% against an EIP, do you think it should still be implemented?

I don't think bias among EIP editors is my only or even primary concern. What happens when EIP editors disagree among themselves on what constitutes Ethereum philosophy? How are EIP editors to tell the difference between a small group of loud and dedicated malcontents and a massive public backlash? I think we simply need more data.

And as I said before, having a better way than spamming GitHub for people against certain EIPs to make their voices heard should make the lives of editors a lot easier.

I must confess, I have misunderstood the governance process and probably continue to misunderstand it in some (hopefully small) ways. Thanks for helping to explain it better.

[jpitts]

Note: consolidated and simplified several comments into one.

RE: voting: An 80% carbon vote may not represent a consensus. Votes based on the holding of ether can be thought of as measurable or fair, but may not address key technical/format concerns and result in a decision that badly affects the network and important stakeholders.

Who has the most weight in decisions needs to be very carefully established.

RE spamming out of concern: It is important to illustrate this because this indicates a larger process problem. The objecting posts in controversial EIPs represent a need to be heard that is not being addressed.

Getting moral/ethical/legal/philosophical is not appropriate for Standard EIPs, but perhaps applicable to a Meta EIP like this one. EIP editors have a clear set of duties to perform, and comments in an EIP should help this work along.

From EIP-1:

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 term "Ethereum philosophy" is not defined in EIP-1, yet it seems to carry a lot of weight. Does keeping to a philosophy invite us to debate whether the EIP, once mature, should be accepted? Well looking this term up in the wiki, I find that "Ethereum philosophy" is actually a set of design principles, followed by an explainer + vision blurb.

If this is the case, it means that there is even less of a basis for debating about M/E/L/P in EIPs. Or those interested could work on the philosophy.

[sfultong]

I feel I need to stress again that when I'm talking about a carbon vote, I'm not talking about using it as the sole determinant of whether EIPs are implemented in clients. I think that having it as a veto power seems appropriate, though.

If 80% of a carbon vote is against an EIP, though, I think that either the EIP must be terribly flawed, or the distribution of wealth in Ethereum is terribly unbalanced and not representative of most members of the community.

If the latter is the case, I think drastic measures should be taken outside of normal governance, but that's beyond the scope of this issue.

[jpitts]

@sfultong could you re-phrase the proposal to be specific about how a carbon vote might be employed in the process, and what aspects it would add or modify in the current EIP process defined in EIP-1?

Looking more into this, I realize here that the AllCoreDevs group is not even described in EIP-1, nor is EIP acceptance itself (only what is required to accept). This is an opportunity to clarify these important aspects of the process, and an opportunity for you to propose more formal inclusion of voices from the wider community.

Note: I am undecided about any changes to the de-facto working EIP process. Changes to the process require more research and especially needs-gathering before I make my own judgement.

An example of what you might put into your proposal:

This Meta EIP proposes to introduce a "community review" step in the EIP process, allowing certain stakeholders to veto the acceptance of an EIP in certain cases involving a hard fork. This Meta EIP also proposes to formalize the current operating role of AllCoreDevs as a "developer review" step in the EIP workflow. The effect of this proposal would be to modify the operating EIP process as well as the process described in EIP-1.

The "developer review" step in the EIP process applies to all Standard Track EIPs, and is performed by the AllCoreDevs group. In order for any Standard EIP to be accepted, consensus must reached during the "developer review" step that the EIP is acceptable.

The "community review" step would only apply to "Standard Track / Core" EIPs (e.g. those leading to a hard fork). It would occur after AllCoreDevs have reach consensus that the EIP is acceptable. "Community review" will use the carbon vote mechanism and require 80% approval. If "community review" has less than 80% approval, the "Standard Track / Core" EIP cannot be accepted.

[sfultong]

Thanks for the guidance @jpitts

I've opened a new PR: #904

My proposal is a bit different than your example, but I like your example as well and would be glad to modify my PR to be more in line with it.

[jamesray1]

It's interesting that the search results for Ethereum philosophy refer to an old version of the White Paper, while the current version does not have such a philosophy and list of principles.

Old version: https://github.com/ethereum/wiki/blob/c02254611f218f43cbb07517ca8e5d00fd6d6d75/drafts/%5Benglish%5D-old-ethereum-whitepaper.md#philosophy

Current version: https://github.com/ethereum/wiki/wiki/White-Paper