Skip to content

Instantly share code, notes, and snippets.

@edsonayllon

edsonayllon/eth-hf-brainstorm.md

Last active September 9, 2020 15:11
Show Gist options
  • Save edsonayllon/e9b91a2c3a8e2d4e242cfc236162e106 to your computer and use it in GitHub Desktop.
Save edsonayllon/e9b91a2c3a8e2d4e242cfc236162e106 to your computer and use it in GitHub Desktop.
Download ZIP
Possible Hardfork Coordination Processes
Raw
eth-hf-brainstorm.md

Scope

Creates several ideas for hardfork coordination to select from.

Statuses

1.

  1. Eligible for Inclusion - Open for discussion for entering a hardfork
  2. Implementation - Decision to have clients include the EIP, before testing
  3. Testing - Decision to have EIP tested, testnet/state tests/fuzzing, etc.
  4. Staged - Decision to go to mainnet and decision on which date to release (block number)
  5. Deployed - EIP is live
  6. Rejected - An EIP fails moving from one step to another, can happen at any time.

2.

  1. Stage 1: Sentiment - Gather sentiment from community/stakeholders for demand of EIP
  2. Stage 2: Refinement - EIP is implemented and tested in clients, and spec is adjusted to become final
  3. Stage 3: Deployment - A time for release is chosen, and released

Unstaged - EIP is withdrawn for consideration into a hardfork

3.

  1. Eligible - EIP is mature enough to be discussed for mainnet
  2. Estiimated - Development schedule is estimated
  3. Developing - Reference implementations are being made in all clients
  4. Public Review - May include auditing, testing, and final request to changes in the spec
  5. Final Approval - Both the EIP is approved to be final (frozen), and approved for mainnet
  6. Final Release - EIP is live on mainnet
  7. Maintenance - Review/monitering period after EIP is launched on mainnet

4.

  1. Eligible - For consideration
  2. Functional - Status meaning the EIP works as expected (implementation)
  3. Secure - There is proof that the EIP poses no security risks (tested)
  4. Deployed - Status meaning the EIP is live on mainnet

5.

  1. Stage 1: Considered for Inclusion - Open for discussion for entering a hardfork
  2. Stage 2: Implementation - Decision to have clients include the EIP, before testing
  3. Stage 3: Testing - Decision to have EIP tested, testnet/state tests/fuzzing, etc.
  4. Stage 4: Staged - Decision to go to mainnet and decision on which date to release (block number)
  5. Stage 5: Deployed - EIP is live
  6. Rejected - An EIP fails moving from one step to another, can happen at any time.

Moving from One Status to the Next, Individual Ideas

Keep doing it how we already do it, just define it formally

Self explanatory. We just write down the process, so it looks formal.

Something like.

  • Decided on the ACD call
  • People who would like to say yes or no, can join the call, or comment on the Discussions-to section/PRs
  • ACD ultimately decide what goes in, but must discovery what the community wants first

No votes, Decided on meeting criteria

Instead of votes, it meets certain criteria, or doesn't meet negative.

Decide a list of qualities. Decide a scale to evaluate these qualities. Decide a success and fail threshold for that scale.

Example. Scale can be from -5 to 5. Negative means reduces the quality from the current clients. Positive means improves that quality from the current clients. Threshold may be being net positive.

Example qualities:

  • Security - Does it improve security, or does it introduce security threats?
  • Economics - Does it improve or damage Ethereum's economy?
  • Unity - Does it threaten a chainsplit? Is there consensus?
  • Performance - Does it improve performance, or worsen it?
  • Simplicity
  • Modularity

Proxy Votes

Moving from one status to another is done by votes resulting in a motion to the new status.

Here, the decision-making is both syncronous and asyncronous. Final decisions are made live on the call. But the decision topics will be announced 1 week before this live meeting in the Agenda. Those who cannot be there for the call (timing) can vote by proxy. By proxy can be with a vote posted on a public forum (Gitter, EthMagicians, or Discord, etc.) or by telling a teammate to give a vote on their behalf.

Live votes and proxy votes are counted in the live meeting, and the decision is made publically to motion an EIP.

Memberships Model

Moving from one status to another is done by votes resulting in a motion to the new status.

Votes are public, identifiable for who voted on what.

One member has a voting power of one.

Memberships are approved by vote of existing members. This is with the intent that only people with expertise do voting. Expertise may also change from EIP to EIP (ie. an economist may be more of an expert with EIPs that change monetary policy, vs a security expert on security EIPs).

Entity Voting Model

Moving from one status to another is done by votes resulting in a motion to the new status.

One entity (which may include multiple people) has a voting power of one. Only entities may vote. The entity vote must be representative of the majority of votes within that entity.

Entities eligible are any entity which builds on, or provides an important function to the Ethereum ecosystem.

  • Ethereum Foundation
  • Ethereum Clients (1 vote per client)
  • Protocol working groups (eWASM, Solidity, etc.)
  • Mining pools
  • Wallets
  • Popular dapps
  • Community vote (no entity affiliation, but all rounds to one vote based on majority)

If one entity owns several other entities (parent companies), only the parent entity may vote (ie. one company that own several popular dapps).

Increasing Scrutiny Model

A mix of processes.

Here, it's easier to progress in earlier stages, but harder to progress in later stages. An example, Eligible for Inclusion can be decided without proxy votes, and only with Core Dev approval on a live call.

However, moving in later stages requires a formal vote from more stakeholders. The number of stakeholders required increasing as progress moves on.

Example:

  1. EFI - Motioned by core devs in live call
  2. Implementation - Motioned by client teams, including proxy votes
  3. Staging - Motioned by client teams, mining pools, and protocol working groups, these additional stakeholders required to vote to pass

Constant Scrutiny Model

Whatever process is chosen, it's followed for every motion to the next status.

Example:

  1. EFI - Proxy votes and live votes by all clients
  2. Implementation - Proxy votes and live votes by all clients
  3. Testnet - Proxy votes and live votes by all clients
  4. Staging - Proxy votes and live votes by all clients

Committees Model

Different committees are made representing different expertises. EIPs are funnelled to different committees based on the nature of the EIP. The committee that has responsibility for that EIP decide when it moves from one status to another.

Supermajority to Majority voting

If the number of votes is less than a threshold, say 10, a supermajority is needed. If the number of votes is above a second threshold, say 20, just a majority is needed (above 50%). Anything in between thresholds needs 75% majority.

Smart Contract

Voting is done via smart contract using Ether.

On Chain

An onchain voting mechanism is made.

Off chain

Decisions are kept off chain.

Oscillating Priorities

Each hardfork the priority changes from EIPs adding new features, to EIPs improving security and performance of existing features/clients (ie. addressing gas fees or state bloat).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment