Governance discussion - referendum ballot mechanism


#1

Communities governed by consensus may occasionally be compelled to plan for significant events that can affect the mechanism of government itself. As such, it is worth discussing whether qualifying significant events merit an elevated level of scrutiny and participatory notice. This unique mechanism is presented for discussion here as a “Referendum Ballot.”

A "Referendum Ballot " or vote meeting certain criteria would be created and scheduled, with a minimum 48 hour and maximum 14 day voting period. The ballot completes successfully at the end of the voting period when the minimum quorum has voted. An affirmative outcome triggers a smart contract that sets a date / time period for a future event. Examples of a future event include a “Hard Fork” that fundamentally changes blockcahin participation, or an election that demands advanced notice and maximum opportunity for voter participation to decide an event at a specific election date and limited time period. This “Referendum Ballot” mechanism solves potential communications and time-frame issues.

Example Referendum ballot for discussion: - Ballot is created with 48 hour voting window - description of the ballot: “let’s have a hard fork + 14 days from today, requiring all node participants to upgrade and verify on or before that date or be dropped from consensus.” Upon successful ballot approval, hard fork configs can be added and must be in place on or before the approved event (+14 days from end of ballot). Validator nodes that do not participate (having had 14 days notice of necessary code update) are removed, at least temporarily, from consensus, and network integrity is maintained.

Interested in the community response and ongoing discussion.

Respectfully submitted for review by Jim O’Regan, January 20, 2018


Governance - Ballot Types and Forms
#2

Great idea. I am down to create such ballot type.
I would need to ask you to create an issue in Github where we keep all our things that needed to be done


#3

I like this; however - I have one issue:

Voting and Potential Actions that are Triggered Must be kept separate and distinct.

In the example of the HF: Totally agree with a 2<->14 day window. However, to add an action could have chilling effects.

EX: Such a ref ballot is put forth, I could see many performing the upgrade without a meaningful debate because they don’t wish to be dropped. Or perform an upgrade without even realizing that they need to vote (trust me on this one.) What about the case whereby I vote/upgrade - only to have the ballot fail (I’ve unintentionally HF’ed from the mainnet.)

I would much rather have a vote (and a health debate period). Followup action (or inaction) at a later date. This is what we do already in the states. Advance an idea, debate/vote, and the actual rule making/enforcement comes much later.


#4

Hi Jeff. Yes, the proposal for a “Referendum ballot” is designed to allay your concerns. Here is the paragraph from the Referendum ballot proposal, broken down a bit more:

  1. A "Referendum Ballot " or vote meeting certain criteria (yet to be determined) would be created and scheduled, with a minimum 48 hour and maximum 14 day voting period. The ballot completes successfully at the end of the voting period when the minimum quorum has voted. - NOTE: The ballot outcomes determines whether or not to initiate an event with notice.

  2. An affirmative outcome triggers a smart contract that sets a date / time period for a future event. NOTE: Positive outcome sets a date / time period - read as election date and debate period - this is the period outlined in the Referendum ballot.

  3. Examples of a future event include a “Hard Fork” that fundamentally changes blockchain participation - NOTE - this can be a necessary technical action, and the Referendum ballot sets the date and time for action -, or

  4. an affirmative Referendum ballot can schedule an election that demands advanced notice and maximum opportunity for voter participation to decide an event at a specific election date and limited time period. NOTE - consider example of setting an election + 60 days in the future to determine the adoptions of rules to qualify “official” POA clone blockchain certification criteria. The debate period is 60 days, the new ballot becomes active in 60 days and 1 second, stays active for 12 hours, which is the voting window for the actual election. This mirrors United States Election law in most jurisdictions. The debate period / Election date and voting period must be set in the “Referendum ballot.”

This “Referendum Ballot” mechanism solves potential communications and time-frame issues.

I hope this has provide some clarity, and I look forward to discussion.


#5

A concern that I have - at the moment all of our ballots have been of type: Yes/No.

I could see future proposals that are a bit more complex and/or validators (for whatever reason) unwilling to make a Yes/No selection. Therefore, if there is the potential for being removed from their network for failure to vote - there needs to be a means of abstaining or otherwise declining to vote. (Participation still being captured)

In countries that require citizens to vote - how are ballots structured?


#6

I really like the approach.

As JIm pointed out, the act of voting is the last step of a process, the others are ( and potentially more important are ):

  • Ballot Creation ( a la Referendum Ballot )
  • Ballot Debate ( was wondering out loud with Jeff the other day … how do we capture this process/data … on-chain, external tool? )

finally

  • Ballot Vote

I think Validator Participation is a function of all (3) above and perhaps weighted towards the first (2).

For example, if someone is votes on all ballots yet doesn’t create ballots nor are they active in debate process then are they “participating” – I would argue “no”.


#7

Sure, I just want to make certain that these other vectors are properly accounted for. I’d hate to see someone fail to perform the metric of interest - I like to be extra cautious for fear of losing a great contributor.


#8

Hi Jeff, the example for removal from consensus was in the case of a hard fork to maintain network integrity:

This gives us a mechanism to maintain network integrity. Total notice period in the example is at least 2 days for the Referendum vote and 14 days to the hard fork - 16 days total. A Validator is not required to vote in the referendum and the Validator nodes ARE required to participate in the hard fork to maintain network integrity. If they don’t participate in the Hard Fork,by installing necessary code updates to nodes, they have at best neglected and at worst relinquished their responsibilities to the network and as a POA Validator. While we don’t expect this behavior, simple steps like temporarily removing a Validator node help maintain system continuity.


#9

Hi John–

this forum may be as good of a place as any to capture debate; what do you think of identifying this as the official venue for ballot discussions? I like your idea of somehow registering participation on the blockchain. If there are team members with distributed ledger experience we may be able to establish an immutable record that other POA.network participants could model.

Great discussion and exciting times!


#10

I suppose then one of my concerns was due to language. One cannot remove a node externally, should a hard fork happen. Rather, that node has removed itself from the “other” chain. I’m extra sensitive to the use of ‘force’ - even virtual.

+++

As for the 16 days (potentially that is) for a hard fork, I’m thinking that this might be too aggressive - particularly in the future where validators come from a lesser tech heavy background. After all, everyone here is by definition comfortable with technology. This might not be the same in the future. (And I’m not sure this is good even now - what about cases where validators are traveling…etc…)

If we can better demonstrate the ability to get out the word, debate -> then vote -> then act, then maybe. The first part is still forming, so I’d rather we go slow on the later portions for now.


#11

Jim,

Regarding:

what do you think of identifying this as the official venue for ballot discussions?

I am not sure.

I imagine that the forum may be a good place for general “Yes/No” discussions on a particular Ballot.

That said, seems like we’d like some of this debate data on-chain as public record and so it can be queried and analyzed.

Imagine that the “Yes/No” positions are formalized/summarized and it is stored on-chain as public statement and record.

Roughly something like this, … but stored on-chain.


#12

Regarding punitive actions.

I agree with Jeff … think going slow is right approach.

There should be some “well-defined” processes and “participation” metrics defined before someone is censored or removed.


#13

Hi Jeff–

I’ve re-read my original post and updated comments to be clear that I am suggesting temporarily removing a Validator node from consensus that has not participated in a necessary code update, and not suggesting removing the human validator.

A hard fork was used as the example since sometimes action may be driven by external forces outside the control of the network. A particularly vicious software or network exploit may demand action within a window to avoid catastrophic network impact, and it is important (or at least desirable) to have a mechanism in place.

A un-patched Validator node could easily (and temporarily) be removed from consensus by removing peer access from all other active nodes; no external force or action is necessary. This is important, since a non-compliant node with 15 peers would continue to fill logs, degrade at least the appearance of network performance and add network load until the node is excluded. Once the software patch or new code is applied, notice can be shared via netstat that the Validator node is back in service. No force involved, and a secondary method of contacting the actual Validator responsible for the node and its maintenance.


#14

Hi John–

I’ve re-read my original post and updated comments to help clarify that I am suggesting temporarily removing a Validator node from consensus that has not participated in a necessary code update, and not suggesting removing the human validator. Sorry for the lax wording. I’ve added a longer explanation to Jeff’s response below discussing how and why excluding a non-patched Validator is desirable and controllable through network action.


#15

This is a great and much needed discussion. Governance requires formal process of proposals, debates, public opinions, and ultimately votes. Ideally all of these would be captured on the blockchain.

+1 on taking it slowly. Governance requires discussion and analysis and can’t be rushed. Reaction to critical events is not so much governance as enactment of emergency protocols (e.g. temporary suspension of a misbehaving node)


#16

I really like John’s Mockup of a Yes/No page - I realize that this is super complex, but something to strive for.


#17

Michael,

Really appreciate you distinction between governance and “emergency protocols” especially related to security. Made me think.

I’ve reconsidered my position and think that security of the network is paramount and protocols should be in place to detect suspicious activities on the Consensus protocol level as well as any “non-compliant” Validator behavior no matter how innocent ( not upgrading a HF within the requisite window … what ever that may be ) etc.

We have a duty to protect the value of the network so any “punitive” action should be interpreted in that context and not be taken personally.

Would hate people to lose tokens or the integrity of the network compromised over “niceties”

So I feel that security and emergency protocols should be a priority in Validator discussions.

John

–Safety is no accident and just because someone is paranoid doesn’t mean people aren’t out to get them. :slight_smile:


#18

I just read about the work being done for a smartphone app and a notification services system. I believe that these tools will greatly help frame emergency protocol discussions.

Anything that might help close the time gap for communication for emergency actions helps. Reminds of how bitcoin qt used to have this built into the code.


#19

One way to separate comms for emergency protocols from general governance, is that emergency protocol comms, which help secure the blockchain, should arguably not rely on the blockchain itself, while our governance model should be built as much as possible on top of the blockchain.

I’ve brought up today in the conf call the option of voting on the agenda items for the periodic validator meetings, where validators could propose topics for the agenda two weeks ahead of the meeting, and then vote on their priority during those two weeks. Ballot would be finalized a day before the scheduled meeting. This would let us apply POA balloting system to a good and regular use and help make it even more usable and useful.

-MM


#20

As there is renewed interest in this and similar topics, I am responding to the original post: “Governance discussion - referendum ballot mechanism” from January 19, 2018, almost 5 months ago from the time of this note.

The original post and follow up may be interesting for all of the new Validators that have joined POA Core and Sokol networks since that time. It would be great to hear new voices on this topic. Thanks in advance!