A Few Thoughts On The EOS Referendum Proposal Process

eostribe (55)in #eos • 6 years ago (edited)

As the EOS referendum UIs and underlying vote tallying infrastructure nears completion, everyone is excited to see the governance layer of EOS unlocked and the process of rallying support for a proposal, getting it voted in by a 2/3 + 1 majority of BPs so it is implemented on the Mainnet will soon be a reality.

In my initial proposal on the referendum process, I collected some of the preliminary discussions and concerns I heard in the community and solicited public feedback to see what people thought.

I then posted my thoughts on the best way to attack the voting UI and suggested a user centered approach with a big focus on education (which is also now partially coded and being finalized for public beta testing in the coming weeks).

We even did a round table of many of the people involved in the project (Daniel Keyes, @jesta, @thomasbcox, etc...) and recorded it on The State for good measure...

The Proposal Process Is Evolving

Some of the early conversation suggested that only the top 21 Block Producers vote on the very first referendum proposals (to mitigate spam), which was later expanded to the top 50 block producers, and most recently the top BPs in the 0.5% range (anyone collecting block rewards).

There is a lot more to this process than you might think at first glance. Actually taking referenda from the proposal phase to something that is implemented on the EOS mainnet requires special care and attention to detail. I will touch on this a bit, but expect EOS Alliance to collect all comments and considerations from the active community in their referendum series next week.

My goal with this post was to drill into the standards and process being discussed in the working groups. None of it is written in stone and subject to change based on feedback and insights from the community.

The project has evolved as new schemas and tallying capabilities become available. It is important for the community at large to understand that things will change and evolve over time.

Thinking It Through Together

There are a few things we as a community need to consider before the referendum voting UIs and public proposals open up. In this post I wanted to share some of the thinking behind the EOS Votes project (the community voting portal being developed as we speak).

We at EOS Tribe think it's important to share the most current conversations happening to gather feedback from the community. Everyone working on the project is doing the best job they can do for both EOS token holders and the BP community tasked with implementing changes as a result of referendum. We all welcome feedback and criticism during this process.

The Gotchas

When submitting a proposal for referendum, there are a few gotchas we need to consider.

- Does The Proposal Have a Github Pull Request?

It's easy to get excited and the EOS community at large to start voting on anything and everything, but there are some serious concern when you start to really think it through.

If a referendum was voted in without a specific piece of code or mark down (in the case of the constitution), who would be responsible to implement the change being proposed?
Are The Block Producers Responsible?
What if the change was extremely complex and required months of testing? What if the change was not feasible and would would break the mainnet?

These are all scenarios to think about when submitting a referendum proposal. In our current thinking, all referendum proposals must have an associated Github pull request (or publicly accessible git repository) for the changes being suggested in the proposal. People wanting to make a proposal involving code changes could submit a Worker Proposal through the EOS WPS to contract someone to code the change, test it and put the code into a pull request on the main EOS repo before the proposal is submitted officially.

- Has The Code In The Pull Request Been Tested On A Public Testnet?

Once again, even if there is a pull request associated with the proposal, we need to think about the implications of implementing code that hasn't been fully tested.

Has the code being suggested been tested on a public testnet?
If code that hasn't been tested and is introduced to the mainnet then causes problems, who is tasked with fixing it?

Again, it would fall on the block producers to clean it up/fix it and we at EOS Tribe know first hand that job is hard enough as it is. Being expected to test every piece of code from every referendum proposal that pops up is not sustainable. It should be on the proposer to test their code before submitting a referendum proposal.

- Has The Code Been Audited By a Third Party?

As stated previously, we need to seriously consider the implications of code that could have security issues. Also, we need to think about who is tasked with fixing issues caused by code that hasn't been tested and think about how to scale this process in the future.

Who would develop and approve a list of trusted third party companies to audit code submitted in referendum proposals?
In the interim, do Block Producers audit the code?
If the code is found to be buggy and/or have security issues, does the proposal get rejected?
If code that has security issues and is introduced to the mainnet, who fixes it?

Removing The Liability and Risk For Block Producers

With all of that said, there are currently four basic rules being discussed for proposals:

You Must Have A Github Pull Request Associated With Your Proposal
If There is Code Associated With Your Proposal, It Must Be Tested on a Public Testnet (Jungle, Kylin, etc...)
If There is Code Associated With Your Proposal, It Must Be Audited By a Third Party (and results must be shared publicly, maybe even on chain)
If Any Referendum Proposal Is Voted In Without Requirements 1-3, Block Producers Can Reject It

Referendum Proposal Process Current Day

So let's visualize what that looks like for those of you who are totally confused. The process as it stands today looks something like the explainer graphic above. Although not perfect, in our discussions so far, we wanted to stick some basic principles...

Don't Make Too Many Rules, Make The Right Rules
Keep It Simple Stupid For Block Producers
Remove Risk & Liability For All Parties

This was the foundations of our thinking up until this point, but we welcome the EOS community to rip it apart and tell us why we are doing it wrong. It's all part of the process.

Special Thanks

This project in it's current form wouldn't exist without the hard work of the following people:

Daniel Keyes (EOS Nation) for project management & content strategy for EOS Votes Portal
Alexandre Bourget (EOS Canada) for his work on eosforumdapp
Denis Carriere (EOS Nation) for his work on the tally application
Michael Fletcher (EOS42) for his work on our first smart contract iteration
Aaron Cox (Greymass) for his DPOS expertise and commitment to integrating into the Greymass wallet
Nathan Rempel (GenerEOS) for his support with he EOSVotes UI and commitment to integrating into EOStoolkit.io
Anna Taylor (EOS Tribe) for her work on the content strategy and educational content for the EOS Votes portal
Josh Kauffman (EOS Canada) for his insight into worker proposals and help with community outreach
Sharif Bouktila (eosDublin) for recruiting volunteers and getting the ball rolling
Thomas Cox for his guidance and encouragement