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

[jpitts]

@jamesray1, that is very interesting!

Why was this set of design principles taken out?

1. Simplicity
2. Universality
3. Modularity
4. Non-discrimination

Perhaps it is time to bring these back, update them, and have them guide the standards work.

As a side note, in the "Old version" that you linked to, "2. Universality" contains something that struck me as very interesting, alarming, and hilarious at the original time of reading:

Want to set up a full-scale Daemon or Skynet? You may need to have a few thousand interlocking contracts, and be sure to feed them generously, to do that, but nothing is stopping you.

[jamesray1]

I don't know why https://github.com/ethereum/wiki/blob/c02254611f218f43cbb07517ca8e5d00fd6d6d75/drafts/%5Benglish%5D-old-ethereum-whitepaper.md#philosophy was removed. As you can see the last commit was in 2015. I haven't made many changes to ethereum/wiki but I have made several changes to https://github.com/ethereum/wiki/wiki.

There is a philosophy page here: https://github.com/ethereum/ethereum.org/wiki/Philosophy. I made some changes to it by moving the technology part to a separate page and linking to it.

I have linked to https://github.com/ethereum/ethereum.org/wiki/ in the sidebar of https://github.com/ethereum/wiki/wiki.

I don't want to trawl through the change history of the white paper, but I can put it back in.

I did make a lot of changes to the white paper, but it was mostly minor changes from an editorial lens: grammar, references, clarity, etc. (which I have done a lot for Ethereum docs, unpaid). I certainly didn't delete swathes of text. That old version looks significantly different from the current one. I don't think the content changed much between when I edited it and how it is now.

Want to set up a full-scale Daemon or Skynet? You may need to have a few thousand interlocking contracts, and be sure to feed them generously, to do that, but nothing is stopping you.

Haha, yes I also laughed at that.

Parts of it is outdated, so they need to be fixed if it is going to be re-added.

[jamesray1]

1. Simplicity - the Ethereum protocol should be as simple as possible, even at the cost of some data storage or time inefficiency.

I agree that it should be as simple as practical, but it may be necessary to have quite a high level of complexity, for instance to scale, to internalize costs of storage, bandwidth and I/O, for security, privacy, transparency, etc. Where complexity is necessary, documentation should be as clear, concise and up-to-date as possible.

An average programmer should ideally be able to follow and implement the entire specification, so as to fully realize the unprecedented democratizing potential that cryptocurrency brings and further the vision of Ethereum as a protocol that is open to all. Any optimization which adds complexity should not be included unless that optimization provides very substantial benefit.

I mostly agree with this, although note it does say ideally, and most people would consider the current specification difficult to read. It takes time to really read and understand it.

2. Universality - a fundamental part of Ethereum's design philosophy is that Ethereum does not have "features". Instead, Ethereum provides an internal Turing-complete scripting language, which a programmer can use to construct any smart contract or transaction type that can be mathematically defined. Want to invent your own financial derivative? With Ethereum, you can. Want to make your own currency? Set it up as an Ethereum contract. Want to set up a full-scale Daemon or Skynet? You may need to have a few thousand interlocking contracts, and be sure to feed them generously, to do that, but nothing is stopping you with Ethereum at your fingertips.

It would be good to talk about abstraction here. The latest roadmap, scroll to the bottom of the top post is actually also looking to abstract execution, allowing execution engines to not necessarily have to follow one canonical specification, but for instance it could be tailored for a specific application, as well as a shard.

3. Modularity - the parts of the Ethereum protocol should be designed to be as modular and separable as possible. Over the course of development, our goal is to create a program where if one was to make a small protocol modification in one place, the application stack would continue to function without any further modification. Innovations such as Dagger, Patricia trees and RLP should be implemented as separate libraries and made to be feature-complete even if Ethereum does not require certain features so as to make them usable in other protocols as well. Ethereum development should be maximally done so as to benefit the entire cryptocurrency ecosystem, not just itself.

This is outdated, I suggest rephrasing this to:

Modularity - the parts of the Ethereum protocol should be designed to be as modular and separable as possible. Over the course of development, our goal is to create a program where if one was to make a small protocol modification in one place, the application stack would continue to function without any further modification. Innovations such as Ethash (see the (Yellow Paper Appendix) and [wiki article])(https://github.com/ethereum/wiki/wiki/Ethash), modified Patricia trees (Yellow Paper), wiki) and RLP (YP, wiki) should be implemented as separate libraries and are feature-complete, and as part of Ethereum, even if Ethereum does not require certain features, so as to make them usable in other protocols as well. Ethereum development should be maximally done so as to benefit the entire cryptocurrency ecosystem, not just itself.

4. Agility - details of the Ethereum protocol are not set in stone. Although we will be extremely judicious about making modifications to high-level constructs such as the C-like language and the address system, computational tests later on in the development process may lead us to discover that certain modifications to the algorithm or scripting language will substantially improve scalability or security. If any such opportunities are found, we will exploit them.

This is also out-dated, and is harder to update. C-like language doesn't even work any more, I don't know what happened to it. I suggest changing it to:

4. Agility - details of the Ethereum protocol are not set in stone. Although we will be extremely judicious about making modifications to high-level constructs, for instance with the sharding roadmap, abstracing execution, with only data availability enshrined in consensus. Computational tests later on in the development process may lead us to discover that certain modifications, e.g. to the protocol architecture or to the Ethereum Virtual Machine (EVM), will substantially improve scalability or security. If any such opportunities are found, we will exploit them.

5. Non-discrimination - the protocol should not attempt to actively restrict or prevent specific categories of usage. All regulatory mechanisms in the protocol should be designed to directly regulate the harm and not attempt to oppose specific undesirable applications. A programmer can even run an infinite loop script on top of Ethereum for as long as they are willing to keep paying the per-computational-step transaction fee.

No suggested changes for that.

[jamesray1]

I'm going to take the liberty to put these modifications back into the white paper. If anyone has any objections or wants to make any further modifications, they can feel free to do so.

[jamesray1]

It's back in!

https://github.com/ethereum/wiki/wiki/White-Paper#philosophy

[FaceDeer]

There was just a pull request to change an EIP's status to "Rejected" that was closed because there is no process for non-authors to move a draft to "rejected". I had a look through EIP 1 and although the "Rejected" status is explicitly allowed, there isn't any process given for anyone to move a draft to that state.

The same problem exists for the Deferred, Active, and Superseded statuses. How do EIPs reach those states?

[cdetrio]

@FaceDeer, I outlined the process for reaching Deferred in a reply to @jpitts here: #904 (comment)

Active is a status term which only applies to "Meta EIPs" (i.e. Informational and Process EIPs). This was stated in an earlier version of EIP-1: https://github.com/ethereum/EIPs/blob/2145841c6ab56142d6c9beec5d2aaefd5bb52c3d/EIPS/eip-1.md#eip-work-flow

Some Informational and Process EIPs may also have a status of “Active” if they are never meant to be completed. E.g. EIP 1 (this EIP).

That sentence was unfortunately removed from EIP 1 in a recent PR from @fulldecent that was recently merged: #1100

Superseded is a redundant status term IMO, equivalent to replaced-by. It is not very useful and we could simplify the set of Status terms by removing it.

[fulldecent]

@sfultong Could you please review the latest EIP-1 and the two-week review which we have added? This may address some of your concerns.

Also related work at #1297

This may possibly entirely address your concerns.

[fulldecent]

@sfultong Could you please review the latest EIP-1 and the two-week review which we have added? This may address some of your concerns.

Also related work at #1297

This may possibly entirely address your concerns.

[sfultong]

Thanks for the notification, @fulldecent

My concerns are twofold:

1. Splitting acceptance into technical acceptance and ideological acceptance
2. Quantitatively measuring support/opposition to EIPs

These changes do address my first concern.

As for my second, I think @MicahZoltu has previously stated, to paraphrase, if people don't like EIPs, they can always "fork off". If core devs are wise, I'll assume that they can make appropriate judgements about support in the two week Last Call period.

So I'll consider this issue resolved, and I guess have @MicahZoltu to thank for the addition of the "Last Call" status. Thanks @MicahZoltu !

[fulldecent]

Adding reference for the history of the last call status:

#1100