Governance Voting Concept


#1

Governance Voting Concept

Why?

  1. I feel Ethereum desperately needs an agreed decision making process before the next difficult decisions occur.
  2. Has to be something we can implement now, using existing technology.
  3. Has to be public and fair (though that is very relative).
  4. Barriers of entry must be low and fair but not nothing. .
  5. This paper puts forth the concept for discussion. It is not a complete system with all the rules needed. If there is enthusiasm, it could be quickly matured.
  6. This concept is a system for |Ethereum as it is now. As the ecosystem matures, this must mature also.
  7. Everything is up for discussion.

Summary

This topic proposes a voting system that can be developed and implemented in a short period of time. The system divides the Ethereum population into rings (miners, developer, core devs, security, users and traders). Each ring creates their own voter list before any votes using their own criteria, distributes tokens and have a DAO that allows votes.

Each ring has a set fraction of the votes adding to 100%. When there is a vote, each ring votes with their list voting list. The result counts for their fraction of the vote.

Anyone can propose a vote. All votes have to be approved by a volunteer subset of the rings. The intent is to remove trivial votes. The distribution of the rings can change depending on the topic of the vote. So a vote on the mining payout would have higher emphasis on the mining ring.

More details with an example

This is a specific example of the Primordial soup article How the Ethereum community could begin making meaningful signaling-based decisions


#2

Maybe you can give some more examples or explain why you feel this way?

There is not a lot of support for formal voting in the main principles of EthMagicians (I’m explaining here, not agreeing / disagreeing with you). Specifically, “rough consensus and running code”, which comes from the IETF.

This doc has more info – https://tools.ietf.org/html/rfc7282, and here’s a quote:

We don’t vote in the IETF. In some ways, we can’t vote: Since the
IETF is not a membership organization, it’s nearly impossible to
figure out who would get a vote for any given question. We can’t
know who the “members” of any given working group would be at any one
time, and we certainly can’t know who all of the “members” of the
IETF would be: That’s why we refer to “participants” in the IETF; the
IETF doesn’t really have “members”. Indeed, we often recruit
additional implementers and other experts into working groups in
order to ensure that broader views are brought into the discussion.
So, voting is simply not practical.


#3

For the past year public pressure on Ethereum has reduced significantly. Development efforts are still very strong along many fronts. This should be a time when our internal management and decision-making processes should improve. We have a lot of requirements that need discussion and the crazy external pressure felt in 2017 is dramatically reduced.

However, I feel the rough consensus model is not improving. I am strongly building a feeling that retention of rough consensus is one of the biggest risks to Ethereum going forward. The decision-making process has been slow, difficult to track and almost impossible for outsiders (who don’t understand the Ethereum) to comprehend and have faith in you.

It is quite possible that with side chains and new user interfaces like burner wallets, Ethereum may have real financial usable applications in the near future. I do not feel we will be equipped for the pressure and I don’t see improvements coming quickly enough.

Two specific examples are 1) the decision-making process for the reduction of the mining reward. The core developers did their best to include all stakeholders and I believe they came to a good decision. But the process was slow and considering the value ramifications extremely primitive. It was also quite centralized. 2) The decisions on security reviews for the latest Constantinople release. From what I understood from the EthSecurity Telegram chat the decisions on the review process were not as open as they could have been and the overall budget for the reviews not very large at all. The result was something that could be viewed by outsiders as quite amateur and smalltime. Given the maturity of Ethereum this should not be happening now.

For this reason, I think vehicles for real decisions can be developed and must be developed. The systems can be more open and effective than what we are using presently. Most decisions should be done using rough consensus. I completely agree with that. However, contentious decisions (such as what to do with the locked funds) should not be avoided or it will be difficult for the outside world to have faith in our system.

I will be the first to admit that one coin one-vote is far from ideal. However, I think decision-making processes are possible, workable and needed. There is plenty of room for innovation and change. I think decision-making processes are something we can lead the world in. We have a wonderful opportunity. What we need is not high level of philosophical discussions such as those between Vlad and Nich. We need to start implementing processes.


#4

I would say I widely agree, we need a bit more structure and hierarchy to the decision-making processes in order to reduce noise and increase effectiveness.

Specifically relating to DAOs, I don’t think we need that yet. Many rings (and we have a lot of them) have self-organized to some varying degrees of success at continual working-group style meetings. I believe this type of effort would encourage broader participation along narrow subject bands, and could serve to focus some of the energy in the community if adopted. We don’t need a formal DAO for any of them yet, they’re not that big yet (at least in terms of formal participation). Even the security ring, at 250 members, we only see about 10% participating on a regular basis. That is enough for informal governance to work efficiently.

We can adopt “Rough Consensus and Running Code” both within and across these subgroups as an organizing principle. The purpose of the groups is to focus energy, to give those interested in certain topics a curated feed of information for them to digest and act on.

What we have currently is a floodlight, an unrelenting torrent of energy dispersed in every possible direction. What I want is a bunch of lasers, focusing energy into a directed stream of power, and focus those lasers towards a single point of massive power and effectiveness. A few of them might get misaligned, but even one laser is more effective than a floodlight at cutting through the crap and getting into the deeper issues. </terrible-analogy>


#5

Fun fact: this decision is not confirmed yet :slight_smile: Anything the Core Devs consider to be political tends to be problematic. As @fubuloubu points out, rings / working groups that can take on specific issues, fold in experts, and then come back with a recommended decisions and/or process (see: #working-groups:signaling-ring) seems like a workable way to scale decision making.

I have no idea what the word “centralized” even means any more. Anyone can propose EIPs, anyone can develop code, anyone can suggest that EIPs are included in hard forks. Does a bunch of that take work and expertise? Yup!

Most of Ethereum is still amateur and smalltime. Lack of funding, lack of process. Should “we”* have a budget per EIP / per hardfork? Looking at the Istanbul roadmap, it’s not clear where security reviews fit in.

Do each of the Ethereum client teams have a dedicated security person?

*“we” effectively means the EF at this point, since there is no other we with a bucket of funds.

Anyway, I broadly agree with you – but pretty much I see “voting” as getting involved in the EIP and core dev process. Which is open to anyone.

The ETH1x process is going to be a real test of this.


#6

Looking at that testnet deploy date, that would be my ideal time to get some security people involved, including a few teams on retainer, to do a deep dive into the EIPs and their interplay. (I wrote about that somewhere… Ugh, forgot!)

Yes. Parity has @kirushik, and Geth (really the EF) has @holiman. Still just two people, not enough IMO for a deep analysis even though they do exceptional work. Pantheon also probably has a great team that is hopefully more directly involved in the next hard fork.

I’m not sure what the QA process looks like with either of these teams (I am sure it is adequetely handled!), but QA per feature is not a good substitute for a deep dive on a pending release (frozen codebase, the whole nine)

I’ve said it before (somewhere…), and I’ll say it again: EF needs to put at least 2 teams on retainer for the next hard fork when it is released to testnet (or even leading up to that, to reduce coordination costs of the testnet fork). It shouldn’t cost more than $80k hopefully, and it’s only every 9 months. I’m sure more than that was lost collectively in the ecosystem over the last roll back. Heck, maybe even the news sites can put some money in from the funds they’d be saving not covering such an event.


TL;DR: Set up a recurring hard fork audit fund, have some matching funds or whatnot, and get saving! (or sign a retainer)


#7

Ethereum is the most mature Blockchain to date. If Blockchain’s are going to be a real part of the global finance and business it will need a better decision-making process that it has today. All I am suggesting (On the magicians for them because it is the best platform for this discussion) is that we look at an improved process to use to document decisions from the community.

We are in a unique situation where we can experiment, make mistakes and improve with relatively little ramifications. We should take advantage of it. Frankly, I would like to see us move to quadratic voting soon, but that is a couple of steps further out.

Therefore, I think the question of community voting through some process should be opened up.


#8

Regarding our security team, it’s a bit of a mix between security and testing. On testing, we have @winsvega who’s mainly focused on consensus tests. We maintain two fuzz-testing frameworks, one based on hive and and one libfuzzer, for doing cross-client consensus tests.

The following people are involved in ether vanilla testing or fuzz-testing: Piper Merriam (testing), Holger Drewes (testing), @cdetrio (fuzzing) , @tintin, @wtf (Anuj), @Cryptomental (libfuzzer-fuzzing), @FrankSzendzielarz (hive) and myself (hive/fuzz).

Security reviews of EIPs have implicitly been part of the acceptance discussion. My hope is that it will be explicitly part of the process from now on. After that comes the security testing process, which is what we’ve been building up the capacity for ever since the dao fork (when hive was first created), through the shanghai-forks (which spurned the first fuzz-testing framework).

One of the main points we’ve learned over the hardforks is the importance of getting the features in as soon as humanly possible, so they can be activated for fuzz-testing and verified by other people than the core developers who have all the tools for debugging/testing within the go-specific rust-specific test harnesses.


#9

Nice, it definitely sounds like the process is maturing, and that is a good thing. The last thing I’d like to advocate for is involving external review at the point of go/no-go testnet release, have one or multiple fresh, outside perspectives can often highlight when a critical assumption is wrong prior to the final release process starting. Internal teams are great for the heavy duty work, but you really need the out-of-the-box thinking that outside perspectives bring.


#10

I personally would like to start testnets sooner, since those are the playgrounds for developers and users alike to try out features and root out bugs. As @karalabe outlined in his EIP/EEF, even on a busy testnet we can make a rollout without announcing it – doing the fork as a sidechain which will die after a short amount of blocks, but still getting the replay transactions from the non-forked testnet.

At the point where it’s already implemented and ready to roll out, the EIP itself should be already vetted (before being finalized). It’s in that vetting-process where I think external contributions would be most useful.


#11

I definitely agree, I think each individual proposal is getting enough attention as it is. The process has been a journey, but things are going well.

I think the complex interaction of multiple proposals and the existing assumptions of the chain definitely warrants that type of deep, external review. This occurs best when a testnet release has been completed, so potential issues can be explored in practice.


I definitely agree with the fact that there needs to be more of a formalized release schedule, so we can come to those decision points sooner and avoid last-minute changes.