Governance discussion - on ballots and participation


#1

It is my heartfelt belief that we need to really think hard about time windows. Making certain that these really work for the network.

We just had a ballot with a participation level that I think we can do better going forward. Some of the friction points (in my opinion) are too few communication channels, difficultly in voting remotely (i.e. on one’s smartphone), and time windows that might be a bit too short.

Voting via smartphone (iOS in particular) - I think this will be solved shortly and by some other group (I see a number of projects working on getting MetaMask on the phone). And more effective communication channels - well, we are using telegram but perhaps we need multiple channels. I think that the one parameter we can most easily and immediately tackle right now is bumping up time windows.

A number of validators would have voted, but the clock ran out. I think from this data point (and granted it is n=1 for the most part) we might need longer time windows. Also - and would love to hear from others about this idea - what about validators being able to vote up to and until the ballot is finalized regardless of the clock status.

The clock running out only means that a validator can finalize/close a ballot… but until that moment, others may cast their ballot. Sort of like getting in a line to vote and when the polls are ‘closed’, anyone in line can still cast their ballot (even if the line is moving slowly). My follow question (after others weight in) would be: is this technically feasible.


#2

Regarding … “we might need longer time windows”

One definition of responsibility is “the ability to respond”. Time constraints/inconvenience/making accommodations aren’t these a part of the burden/duty one assumes as a Validator in exchange for the block reward? My take is that 48 hours is a long time in the 21st Century. That said, would support 48 hours interpreted as (2) business days, to eliminate weekends and US holidays from the equation which “normalizes” expectations to traditional work times.


#3

My concern is that we had 50% participation for Walter’s, and ~2+ validators would have voted had it not been for the clock running out. This (granted singular) data point suggests to me the need for slightly expanded time windows.

I do think some of the tools that are in the pipeline will assuage my concerns ( a more complex pro/con rebuttal form; integrated notification system(s); more communication channels ) - but these are not yet here.

I do like the idea of using business days.

Also - what about the case of a difficult vote (either the subject matter is controversial or complex requiring additional research/information)? Perhaps there ought to be a mechanism in which a validator can ask for more time. This is non-trivial, and we’d really need to unpack this idea more.

In the meantime, I’m thinking 48 hours is a bit tight. I do like the idea of business days. What about allowing validators to still vote, even if the ‘clock’ has run out - but another validator has not yet finalized the ballot? I think that these would be great steps in the right direction.


#4

Jeff,

Not a fan of the “voting enabled to Ballot is Finalized” as currently that is not deterministic. This is like Flower’s Paradox ( a la Zeno ) for POA Ballots … “does the voting ever end for a particular Ballot”

I think in general having things well-defined and deterministic is in the end more secure, i.e. “finality” is good …

from https://ethereumreport.org/2017/09/26/blockchain-finality-explained/

“Adding finality to the Ethereum blockchain adds an additional layer of security to the environment, that is currently not found in most other blockchain implementations.”

Athough the above refers to the consensus layer I feel it is relevant to Ballots and a general guideline for systems and a processes ( especially new ones )


#5

Deterministic Vs. Governance based smart contract finality is an interesting topic. I think that because we exist as validators, we should modify our working environment based on empirical data. I realize that my “empirical data” is one datum: Walter’s on-boarding into Sokol having 50% turn out.

Hence why I ask how we can increase turn out. The communication tools that we currently have are in some respects too noisy - and information can be easily lost. I realize that a number of tools are forthcoming, they are not yet here - so I think maybe expanding the time window.

Perhaps we can keep a closer eye, and look at future ballots (wrt voter turnout). If these are also on the low’ish side - then I think we ought to rethink time windows. Maybe this is a case of wait and see, using more data. If there was more data regarding low voter turnout, would you be open to expanding the time windows as a first attempt towards a ‘fix’? (I prefer this solutions over sanction’s based ones.)

As you mentioned finality and blockchains (i.e. onto something completely different): One concern in a future of many blockchains communicating across one another is the issue of finality between. Reorg’s would be exceedingly difficult, and so I’m coming around the the idea of checkpointing Merkle cones as a work around. I do wonder what others think about this, I think it’ll be rather important. Hum… Totally off subject, sorry.


#6
  1. I think it would be good to have an “Action” channel (whichever tool we choose) and that would be only for action calls for Validators:
  • New Ballot got created. Go vote.
  • HF is coming. Update nodes.
  • Etc.

All other questions, ideas, discussions will not be included in that tool.

  1. As we add more validators, threshold for minimum ballot votes should be increased.
  2. Also we might enhance voting dapp frontend and show who already voted. You can see a good example in this forum. Look at this thread… There are small round profile pictures below messages if somebody replied. We won’t show any results on how we voted, just show participation percentage on particular ballot and who already voted. If we want, we could go even farther and collect participation statistics and overtime it would be visible if any particular validator’s participation is very low.

#7
  1. We are independent Validators, responsible and bound by our oath to duties of the network.
  2. The private ballot is private; I believe showing the total votes cast is sufficient; showing who has and has not voted (or how they have voted) can lead to coercion, historically well documented.
  3. Part of our responsibility is to have the tools, talent and motivation to vote in a timely manner. In this day and age, I don’t think it is an undue burden to lug around a small laptop or tablet capable of participating in a vote.
  4. While current ballots have a minimum ballot life of 48 hours, debate has, can and should occur before the ballot begins. In the case of the ballot for Walter that Jeff references as 50% voter participation, there was well over a week time period from the beginning of discussion to the end of the ballot. Well over 48 hours notice before the ballot even began.
  5. The minimum votes were cast (more than the minimum). All rules were met.
  6. I don’t know why Validators chose not to vote in a timely manner. Perhaps it was a choice for some; this is up to the individual Validator. If other Validators are passionate about a particular ballot, they should use the power of their bully pulpit and advocate for their position and strong Validator participation.
  7. We sometimes need dare great things, expend great effort, and accept great responsibility. I suggest we ask each other to do and show our best, lead by example and emulate excellence in our peers, that those to come next can follow a clear, bright path.

Jim O’Regan


#8

I don’t think anyone is suggesting that how we vote being revealed, only that we did or did not. That is, at least for me, reasonable.

Also there is no clear protocol as to debate structures - only min time. I don’t know where " there was well over a week time period from the beginning of discussion to the end of the ballot…" is coming from. The present communication channels are not enough - and I realize more tools are forthcoming (though not presently online yet.)

I’m just saying from the data, we need to look closely and change if it would result in stronger network. One of the strengths of this network is active governance - and we need to be able to adjust in light of the data and our overall vision.

Also, I’m strongly concerned about the 48 hr becoming de facto for all matters. I can see more difficult votes in the future, requiring greater information and debate to arrive at an informed consensus. Once again, I think John’s more complex form for ballots (submitted here and in github), should they be adopted, would be a step in the right direction. But might still need expanded time windows. I can see a number of situations whereby one could game 48 hours rather easily - “selfish validating” if you will.


#9

Looking forward to further discussion!


#10

I don’t like the idea of business days. Our Dapps, network and the whole crypto world work 24/7/365. I believe validators as keepers of consensus for 3rd generation blockchain should be able to adapt to such schedule. If 48 hrs min window is not long enough for most of us then let’s pick the other min window and stick to it. Moreover, what is a holiday in one state can be a working day in the other. This doesn’t scale.


#11

Agreed. The world runs 24x7x365 - holidays are local, blockchains are global.


Sokol Testnet - On Boarding Procedures
#12

Not averse to having a longer voting period but have not seen a proposal above … 72 hours?

Global is nice and all but at this point in the development of the network I prefer practicality and policies digestible for a broad range of individuals. Further there are POA foundation resources being expended on lobbying for US government centric and insurance use cases. As these activities are US centric, in my view it makes sense to make support “business day” logic to the voting period.


#13

John, could you please initiate on-chain vote to have our voting Dapp operate during business hours only? We vote and the majority decides.


#14

We can vote, but just want to mention that “during business hours” to me is more like a restiction rather than convinience

For example if there is a 48 hours ballot, I should be able to vote at any convenient time. Even at 3:00AM


#16

Can we currently initiate an on-chain ballot to increase the min-ballot time to 72 hrs?


#17

I don’t think that it is available at the moment. We have 3 types of ballots that could be created. Time of ballot is not there I believe


#18

Exactly. How do you guys propose to vote then?


#19

Yeah. I for one think that starting a 48 hour ballot Friday at 1am (for me at least - and remember, we only are allowing US validators for Core) is not cool. Nor is it cool to start one on a holiday - and we can simply use Banking Holidays, as these are standardized currently.

I would hope that we all could simply create ballots (after a discussion has been had) at the start of a week. Many software companies do this already - like patch Tuesday for example. Should this be codified, perhaps but I think we need to perhaps create a more general purpose ballot first.

Maybe take a look at the design thread? There’s a version v.0.1 in the works there…


#20

I think we need to first design a ballot - structurally speaking. I’m for the build - refine - build - refine approach. Version 0.1 - a mod’ed form of John’s is up for comments


#21

Unfortunately, don’t believe Voting DApp supports this ballot type.

This is where the Validators need to come up with some specifications for a “general ballot” and add an Git issue or enhancement request to the Governance DApp so can be coded.

Suppose we could just add a Git issue for “Minimum Voting Time Ballot” with minimum never less than 48 hours, the current minimum. Still here we’d even have to specify what the outcome of the successful ballot does so it can be implemented and tested by dev team.

The question is does one person do it a la Nike, i.e. “Just do it” or do we have a small set of Validators ( 2 or 3 ) coordinate and come up with a spec and present to Validator community and have some informal poll