EIP Community Veto

[sfultong]

Draft of Meta EIP for codifying community veto powers and clarifying EIP acceptance procedure.

Closes #898

[MicahZoltu]

Changes to the governance process should be proposed as changes to EIP-1, not as a separate EIP. Though, interestingly, such a change cannot follow the normal EIP process of merging as a draft. 😬

[MicahZoltu]

The community currently has no official procedure for indicating their dislike of certain EIPs.

This isn't true. They indicate their dislike by not upgrading their nodes to run protocol changes. The community's role in the governance process (currently) is that of final veto power. While I appreciate that many people don't like this mechanism and prefer majority (mob) rule, it is incorrect to state that the community has no official procedure.

[MicahZoltu]

Controversial hard forks should be avoided whenever possible

You should specify in the EIP why you believe that controversial hard forks should be avoided.

I personally think that controversial hard forks are the single advantage that this type of governance has over traditional democratic governance.

[MicahZoltu]

The current role of the AllCoreDevs group is also not detailed in EIP-1

Agreed, and EIP-1 should be updated to reflect that. However, creating an EIP that suggests that someone update another EIP for clarity isn't the proper procedure, instead I recommend just submitting a PR for EIP that adds the clarity.

[jamesray1]

A problem with hard forks is that for every fork, people would have to dedicate time and effort to build clients on the new fork and implement changes (e.g. ones that they agree on from EIPs). Voting can provide signalling for decision making on whether to proceed with a change on Ethereum if there is a majority vote (which could also include criteria for key stakeholders like clients, miners/validators, core devs, etc.), otherwise, if not, people can choose to fork Ethereum and maintain the fork as they see fit.

[MicahZoltu]

Yes, the people dedicating resources to authoring a fork are making a bet on where they believe people will trade. However, I'm not convinced that a vote would actually be a valid signal as to the correctness of their actions. As an example, I would have voted against TheDAO, but ultimately when push came to shove I stayed with ETH instead of ETC. If we assume (just for the sake of this discussion) that everyone was in the same boat then the vote would have changed the behavior of the client developers in a way that may not actually have been in the best long-term interest of Ethereum.

At the time of The DAO, I wasn't as well informed as I am now and if the vote were to happen today I may vote differently (I'm not actually sure which way I would vote). The problem is that the vast majority of people (like me) who would be participating in this vote are not as well informed as the people coding the clients. It is just the nature of how the world works, often many people who are affected by a particular issue have not devoted a massive amount of time into researching and understanding that issue enough to make the most wise decision.

[sfultong]

I think it's great that cryptocurrency has the option for communities to peaceably split via hard forks, but I also think it should be the absolute last resort. If a compromise can be found before it reaches the point of a community split, why not?

@MicahZoltu surely you don't think that community splits should be common occurrences, do you?

[TweetyPanda]

Forks lead to more fragmentation which reduces the viability of the community, Standardization through consensus is the norm in most mature SDO's, it would be advisable to maintain at least a set of common standards. A commenting period, where any opposition can suggest how a proposal could be made acceptable, may also improve the incorporation of community comments into an EIP before it starts a decision even needs to be taken.

[MicahZoltu]

Once an EIP champion has polished their draft to their satisfaction, it will go to the "Staging" phase.

This is exactly what merging an EIP as a DRAFT is, what are the advantages to renaming it to STAGING? What is unclear about the DRAFT name?

[sfultong]

My idea is that at the Draft phase, it is undergoing revision, whereas the "Staging" phase would be for evaluating EIPs that are in a stable state.

It's hard to evaluate things as they're being changed.

[TweetyPanda]

Are you referring to making us of the "Draft" phase to allow for free flow comments to be integrated by the author as they see fit, and a "staging" phase that would be pegged against a delivery date to avoid the instability?

[sfultong]

The staging phase would have a community vote window, if that's what you mean by delivery date. Client software probably shouldn't be implementing any EIPs until AllCoreDevs and the community carbon votes have passed.

It's helpful to have the EIP frozen when the community is voting on it, though, so that it's clear that everyone is voting an exactly the same thing.

[TweetyPanda]

I meant "promotion" of the standard, not "delivery"

[MicahZoltu]

The contention around EIP-867 made it clear that there was no good way for the community to make its voice heard

EIP-867 has not yet adopted yet, so we can't say that the process failed in some way. People are worried that the process will fail, but we don't actually have evidence of failure yet. While it is unclear if the yelling in that GitHub issue is meaningful or not, the problem is that is not how the community "participates" in the governance process. They participate by choosing a fork to participate in in the future.

[TweetyPanda]

Whether you support forking or not, would be not be a better process whereby a counter proposal can be reviewed for harmonization prior to fragmenting into a new fork?

[jamesray1]

rammifications => ramifications

[Arachnid]

The EIP process is the wrong place to block an unwanted proposal. Anyone should be allowed to standardise anything that is correctly written and has technical consensus; the place to block an unwanted change is when it's proposed for inclusion into a hard fork.

If you provide a way to "veto" a standard, people will just go off and standardise elsewhere; there's nothing that says hard forks have to use EIPs exclusively to describe changes.

That process could definitely use formalising and improving; I'd suggest contributing to proposals to improve that instead of trying to gum up the standardisation process.

[gcolvin]

@sfultong This proposal does clarify an ambiguous part the current EIP process, which the editors and others also discussing. For your proposal I think all that is needed is that there be a better-defined status for a draft that is done being edited and is ready, technically, for consideration by the core developers.

As for the community veto. Currently, as I see it, when it comes to changes to the clients the developers of the clients call the shots. The EIP process only provides input. So you can't actually prevent the core developers from considering an EIP.

But anyone can of course organize a vote on an EIP independently of the EIP process and submit that as further input to the core developers. That might be more effective anyway.

I agree with Nick that this is probably the wrong place, but if you do want to continue drafting this you need to specify in more detail just how the vote should be set up and run. Perhaps a more general meta-EIP for Ethereum vote procedures.

[sfultong]

@Arachnid @gcolvin

Fair enough. It is easy enough for the community to initiate a carbon vote out-of-band for any contentious EIP, although it could be further automated.

I'll close this PR.

I would like to comment that on-chain governance is increasingly being used in cryptocurrency and it's conspicuously absent from Ethereum. There may be legitimate reasons for that, but I would be more confident in Ethereum if the Ethereum Foundation ate its own dog food.

I guess that the EIP editorial board is independent from the Ethereum Foundation, although I'm not clear why that is, or even why it would be desirable.

Anyway, thanks for the review!

[gcolvin]

@sfultong One reason EIP editors are independent from the Foundation is that they were independent volunteers from the start. In a decentralized community people just organize themselves to do a job, and others either find their work useful or they don't.

[jpitts]

The EIP process is the wrong place to block an unwanted proposal. Anyone should be allowed to standardise anything that is correctly written and has technical consensus; the place to block an unwanted change is when it's proposed for inclusion into a hard fork.

@Arachnid and @gcolvin, what is the current procedure for an accepted Core EIP to be proposed and approved for inclusion into a hard fork?

If such a procedure is not appropriate for the EIP process and EIP-1, should this be documented in a charter/purpose/guidelines adopted by the All Core Devs?

One requirement for inclusion into a hard fork is that an implementation is completed. Are there other requirements in the current procedure?

[cdetrio]

@jpitts in the readme, Accepted is defined:

Accepted - an EIP that is planned for immediate adoption, i.e. expected to be included in the next hard fork (for Core/Consensus layer EIPs).

So if it has Accepted status, that means it has already been proposed and approved. The process for proposing a Core EIP is to submit a draft (open a PR here on the EIPs repo), and then bring it up for discussion on an All Core Devs call by leaving a comment on the pm repo, in particular on the issue where each call's agenda is organized.

[jpitts]

So to take this logic and apply it to a hard fork scenario as it currently functions: when the All Core Devs accepts an EIP w/ a proposed set of changes that would lead to a hard fork, this is the signal to the community and client implementers to go ahead and put those changes into a new release.

[jpitts]

I'm interested in if there's any more work done regarding a Core EIP in the All Core Devs after it has been accepted.

Is there a process in the All Core Devs calls in which a Core EIP that has been already accepted is then approved for inclusion into a hard fork?

I ask this because @Arachnid wrote earlier: "the place to block an unwanted change is when it's proposed for inclusion into a hard fork".

[cdetrio]

To expand further, core developers will then give feedback on the call. If they nod in agreement that they'd like to implement the EIP and include it in the next fork, or if they are at least willing to do so and don't have major objections, then an EIP editor will update its status to Accepted.

Once an EIP is Accepted, that means it is planned for inclusion in the next fork. There is no special treatment for any future features that are on the roadmap for some later fork, such as Casper. EIPs submitted as proposals for a later fork may of course be discussed on a core devs call, but they remain as Draft.

When discussing an EIP, the core dev call participants prefer it to already have at least one implementation that they can refer to, to demonstrate that the proposal is practical and that the details have been worked out. Sometimes an EIP can be provisionally Accepted (the definition is "planned for inclusion", not "will definitely be included") if there is only a rough or proof-of-concept implementation. Then as more developers implement it in multiple clients, the details are fleshed out and debated. If concerns or objections are raised during this process of full implementation in multiple clients, and it is agreed that the concerns sufficiently problematic, or if implementation and testing progress is too slow, then core devs may (on a later call) agree to Defer the EIP, and an EIP editor will update its status from Accepted to Deferred. Once an EIP is deferred, it is a signal that it will not be included in the next hard fork, and developers should instead focus their efforts on implementing the remaining set of Accepted EIPs.

If the implementation and testing progress is satisfactory, given some timeline for the next fork, then final details are debated (e.g. exact gas costs). Simultaneously with the implementation and testing of individual EIPs, core dev calls also discuss a target timeline for the next fork. Eventually, once the set of Accepted EIPs is fully implemented in the major clients, and there is agreement that every last detail is fully specified and that all EIPs are thoroughly tested, then a testnet fork date is proposed, and a testnet block number chosen. At this point, an EIP editor will update the status of the set of Accepted EIPS to Finalized, which is the signal for client maintainers to package new releases that are compatible with the upcoming fork. Once the fork is successfully activated on the testnet, then the mainnet block number is finalized. The mainnet block number can also be proposed at the same time as the testnet block number, and tentatively finalized conditional on a successful testnet activation. This saves client maintainers from having to package two separate releases (one for the testnet and one for the mainnet), and users from having to update twice, assuming a smooth rollout.

[jpitts]

@sfultong, this suggestion for a feedback period on the Fellowship forum continues work on this idea for a community veto: https://ethereum-magicians.org/t/suggestion-to-have-a-community-feedback-period-for-each-eip/47

[sfultong]

@jpitts Excellent, I'm glad.

I think the key piece that I strongly advocate for is increased data gathering.

Something as simple as a community-run carbon vote server that automatically opens votes as new EIPs are merged would probably be enough.