search

livepeer / LIPs

Livepeer Improvement Proposals
9 stars 13 forks source link

Polling system for LIPs #16

Closed yondonfu closed 4 years ago

yondonfu commented 4 years ago

Abstract

This proposal outlines a polling system that tokenholders can use to decide whether to accept or reject the adoption of a LIP. The polling system is based on an a set of on-chain contracts used for non-binding voting and an off-chain indexer used for vote tallying.

Motivation

The goal of the polling system is to give tokenholders a way to voice their opinions on LIPs as an initial step towards community participation in protocol governance.

The polling system design in this proposal seeks to fulfill the following criteria:

The design in this proposal does NOT seek to fulfill the following criteria:

Specification

The polling system will consist of following components:

The frontend used to interact with the polling system is outside of the scope of this proposal.

Definitions

Parameters

QUORUM and THRESHOLD are fixed point numbers using 6 decimal places of precision which matches the precision currently used in the protocol contracts.

PollCreator Contract Interface

contract PollCreator {
    uint256 public constant QUORUM;
    uint256 public constant THRESHOLD;
    uint256 public constant POLL_PERIOD;
    uint256 public constant POLL_CREATION_COST;
    ILivepeerToken public constant LPT;

    // Emitted when a poll is created
    // This event can be indexed to construct a list of all polls.
    event PollCreated(
        address poll,
        bytes memory proposal,
        uint256 endBlock,
        uint256 quorum,
        uint256 threshold
    );

    /**
     * @dev Create a poll by burning POLL_CREATION_COST LPT.
     *      Reverts if this contract's LPT allowance for the sender < POLL_CREATION_COST.
     * @param _proposal The IPFS multihash for the proposal.
     */
    function createPoll(bytes calldata _proposal) external;
}

Creating a poll

While the contract does not support crowdfunding the poll creation cost, anyone can write a crowdfunding contract that submits the createPoll() transaction when the contract has accumulated sufficient LPT to pay for the poll creation cost.

Poll Contract Interface

contract Poll {        
    // Emitted when an account submits a yes vote
    // This event can be indexed to tally all yes votes
    event Yes(address indexed voter);
    // Emitted when an account submits a no vote
    // This event can be indexed to tally all no votes
    event No(address indexed voter);

    /**
     * @dev Vote yes for the poll's proposal.
     */
    function yes() external;

    /**
     * @dev Vote no for the poll's proposal.
     */
    function no() external;
}

Voting in a poll

Off-Chain Indexer

The off-chain indexer keeps track of the following entities:

enum PollChoice @entity {
    No
    Yes
} 

type Poll @entity {
    id: ID!
    proposal Bytes!
    endBlock BigInt!
    // This is a fixed point number that will need to be converted into a %
    // prior to displaying to a user
    quorum BigInt!
    // This is a fixed point number that will need to be converted into a %
    // prior to displaying to a user
    threshold BigInt!
    // This will be updated with each vote
    tally PollTally
    voters: [Voter!] @derivedFrom(field: poll)
}

type PollTally @entity {
    id: ID!
    // Active stake that voted yes
    yes: BigInt!
    // Active stake that voted no
    no: BigInt!
}

type Voter @entity {
    id: ID!
    stake: BigInt!
    // The stake that does not back a vote
    // This can be subtracted from stake to compute the voter's voting stake
    // If the voter is a delegator, this will be null
    // If the voter is an active orchestrator, this will be non-zero if any
    // of the its delegators voted on their own
    nonVoteStake: BigInt
    choice PollChoice!
    poll: Poll!
}

The indexer will index the following poll related events:

PollCreated(address poll, bytes proposal, uint256 endBlock, uint256 quorum, uint256 threshold)

Yes(address voter)

No(address voter)

The indexer will also run a block handler with the following logic:

@adamsoffer is working on an indexer design that enables real-time pollying. This section can be updated with that design once its fleshed out.

nelsorya commented 4 years ago

To clarify, for the voting % thresholds when referring to "active stake" are we talking about total staked LPT?

My initial thoughts on the parameters:

Quorum 20% - I think 20% makes sense initially, however, if we are going off % total staked LPT some of the top orchestrators have between 10%-15% of staked LPT, so it's a very low bar for Quorum.

Threshold 50% - this number seems reasonable to me given governance decisions will default to the orchestrators if token holders do not place their own votes. I think it would be helpful if there was some way of seeing if your orchestrator is actively voting in the dashboard for those which would prefer to delegate governance decisions.

Polling Period 10 rounds - makes sense, if we were ever to have mission-critical changes being decided through governance I think this would need to be lower, but seems fine for now.

Poll Creation Cost - I think 100 LPT at current prices seems appropriate, however, if prices move significantly from where they are now I think this needs to be changed over time to keep it within some target $ cost range.

I saw in Kyber's new Katalyst protocol upgrade (https://blog.kyber.network/katalyst-kyber-protocol-upgrade-and-2020-plans-20427ef47ac6) with the upgrade and new token model, token holders will need to participate in governance in order to qualify for their staking/participation fees.

Given Livepeer's focus on active participation in the early network design, I think adding a requirement for orchestrators to vote in governance proposals to qualify for transcoding fees could make sense from a design standpoint. I would be curious to hear what the team and the wider community think of making a change like this?

kyriediculous commented 4 years ago

Quorum 20% - I think 20% makes sense initially, however, if we are going off % total staked LPT some of the top orchestrators have between 10%-15% of staked LPT, so it's a very low bar for Quorum.

I think it might be too low.

The top 5 staked orchestrators currently own 50% of the total active stake. We don't know how much of that stake is delegated but I think we can also assume that delegates will be less likely to participate in governance than orchestrators.

We are also talking about active stake so those are users already actively participating in the protocol in varying frequencies. I think a 20% quorum would therefore make sense if we are considering total stake but too low when considering active stake.

With that 20% number in mind and a 50% participation target , I think a 40% quorum for active stake would be more fitting.

Given Livepeer's focus on active participation in the early network design, I think adding a requirement for orchestrators to vote in governance proposals to qualify for transcoding fees could make sense from a design standpoint. I would be curious to hear what the team and the wider community think of making a change like this?

I don't think this needs to be protocol explicit. A way of seeing whether an orchestrator is actively participating in governance on the explorer could serve as an additional statistic for delegates to assess orchestrator quality.

That means that not participating in governance could have implicit effects on fee generation for the orchestrator (being able to win less work due to a low total stake).

Poll Creation Cost - I think 100 LPT at current prices seems appropriate, however, if prices move significantly from where they are now I think this needs to be changed over time to keep it within some target $ cost range.

Good point. In the original draft for this spec I proposed adding a uniswap integration in front of creating a poll so that a user could use ETH to create a poll, the contract would swap it for LPT and burn the LPT. We could do it for DAI instead and put a poll creation cost of 100 DAI, which would then be swapped for LPT to be burned.

This can be a seperate contract so it can be a module added on top of this set of contracts.

dob commented 4 years ago

Given Livepeer's focus on active participation in the early network design, I think adding a requirement for orchestrators to vote in governance proposals to qualify for transcoding fees could make sense from a design standpoint. I would be curious to hear what the team and the wider community think of making a change like this?

I like the eventual goal of having orchestrators be mandated to participate in governance. I was thinking that they could be slashed some small % of stake if they fail to participate, though perhaps your suggestion of them being temporarily ineligible for fees or rewards makes sense. Probably better if it's forfeiture of inflationary LPT rewards than fees, because fees incentivize them to actually perform the useful work of transcoding, and that's what we all want.

But either way, I'd suggest that this enforcement incentive be something that the community decides through a future upgrade proposal using this polling mechanism, rather than being bundled into the initial creation of this mechanism which aims to keep things simple.

dob commented 4 years ago

To clarify, for the voting % thresholds when referring to "active stake" are we talking about total staked LPT?

Yes, we are talking about staked LPT. So a 20% quorum would be 20% of the total actively staked LPT. not 20% of the total outstanding LPT.

kyriediculous commented 4 years ago

I think there's two separate discussions here.

I think it's a little out of scope for this LIP but perhaps interesting material for a governance call, since we already have different opinions this could only lead to a very interesting discussion.

yondonfu commented 4 years ago

In the OP, I intended the term active stake to refer to stake that is delegated to active orchestrators. Recall that:

A few of the implications of only giving voting power to active stake:

I suggest that voting power be given to all stake (both active and inactive stake). I believe the benefits of doing so are:

kyriediculous commented 4 years ago

I like the overall arguments presented above but would like to point out a few concerns with considering the total supply

then delegators that do want to participate in governance do not need to worry about losing their voting power when delegated to a relatively low stake active orchestrator that could be at risk of being deactivated

Rebonding to a different O is not free of cost but happens without a time penalty so a delegate will never be out of the opportunity to participate even when delegated to an inactive O when the poll starts. I don't think active set churn at the bottom of the set will be decided by delegates.

yondonfu commented 4 years ago

I like the overall arguments presented above but would like to point out a few concerns with considering the total supply

When you say "considering total supply" here, do you mean giving voting power to all LPT and not just staked LPT?

If so, in my suggestion voting power would still only be given to staked LPT, but it would be given to both active staked LPT (i.e. delegated to orchestrators in the active set) and inactive staked LPT (i.e. delegated to orchestrators not in the active set).

If not, could you elaborate on the concerns you listed? At the moment, I don't see how those points are more of a concern when voting power is given to both active and inactive staked LPT vs. just active staked LPT.

Rebonding to a different O is not free of cost but happens without a time penalty so a delegate will never be out of the opportunity to participate even when delegated to an inactive O when the poll starts

This is more of a concern at the end of a poll. The example I am thinking of is that a delegator votes, but its orchestrator becomes deactivated right before the end of a poll - if voting power is only given to active staked LPT then that delegator would need to try to scramble in a tight time window to move its stake to an active O in order for the vote to be counted.

dob commented 4 years ago

Still need to consider changes in LPT balance over the duration of a poll in the tallying

Even though this is certainly a concern for what people interpret the intermediate status of the poll to be, I think it's solved by the hard-and-fast rule that only the final state at the end block matters. Intermediate status just gives people a view into what's happening with the voting.

chrishobcroft commented 4 years ago

My comments rely largely around the definition of QUORUM, and the proposed initial value.

Definition of QUORUM.

The definition used above is perhaps an over-simplification, and perhaps also misses an opportunity to learn from projects focused on governance:

The minimum percentage of active stake that needs to vote in a poll in order for the poll result to be considered valid.

First, it isn't clear what "active" means specifically in this case. I would appreciate some clarification on this.

Second, I present a counter-example: this is how Aragon define quorum in their literature, and how it is built into their contracts:

Minimum acceptance quorum: minimum % of all token supply that needs to approve in order for the voting to be executed. (source)

So, the difference here is quite nuanced.

Livepeer's definition requires only that QUORUM % of stake actually cast their ballot on a proposal for a result to stand. Whether they vote YES or NO is irrelevant when considering the quorum in this definition.

Aragon's definition is in some ways more strict (and perhaps also more clear). It requires that QUORUM cast their ballot in favour of the proposal for a result to stand.

I don't know which definition better suits this scenario, or this community, but I thought it worth raising the idea to use language and terminology used by other projects in this space, and perhaps start by building on some of their foundations.

(as an aside, I would recommend that whoever is building the contracts to make this happen could do well to review how Aragon built their Access Control Layer (ACL), which effectively grants permissions to contracts to call functions on other contracts. Aragon have been evolving this for as long as Livepeer has been working on video Transcoding :) so why learn from some of their practices?)

Proposed initial value of QUORUM

In short: better to "set the bar high" in terms of required participation, and then lower it if absolutely necessary... instead of "setting the bar low" from the outset, and arbitrarily increasing it to make it harder to hurdle.

Pending any further clarification of the above, I believe that setting the quorum artificially low (20%) while we get things going, would be a mistake.

Initial settings have a habit of becoming set in stone, and the act of changing them to tighten things up becomes too onerous, and we remain stuck with a status quo.

So, I believe that the we should start with as strict a set of parameters as we can stomach, and if things work, great... but if they really don't, it's a parameter which can be relaxed, presumably by a vote, but a vote which requires a very high turnout in order to pass.

This creates the incentive for active turnout (and hence collaboration, participation), because deadlock is no good for anybody in this ecosystem.

A counter-proposal

In short: let the process of agreeing the initial value of the QUORUM become the first at of this democratic system.

We've already seen above that things relating to the QUORUM are quite contentious.

So, my proposal would be to use something closer related to Aragon's definition of QUORUM, and to start with this at 50%. (also THRESHOLD at 50%). In order to pass a vote to reduce this QUORUM, >50% of the voting weight would be able to vote YES.

Note: this would not require 100% of the voting weight to participate, but only enough for us to be sure that a majority agrees.

If we think that it could be too hard for enough people to participate, then I fear we're setting our sights too low as a community.

dob commented 4 years ago

Definition of quorum...

Good point. This was updated in the merged draft LIP to be more clear: "The minimum percentage of stake that needs to vote in a poll in order for the poll result to be considered valid."

It no longer applies to only "active" stake, but instead to any staked LPT even if it is delegated towards a non-active orchestrator. This means you need to be committed to the network for at least the length of the unbonding period in order to vote, but you don't have to actively monitor whether your O remains in the active set or not.

Side note: perhaps the discussion issue itself needs to be updated to reflect these changes so that people following the discussion have all the latest context.

Initial value of quorum

Yes, definitely heard the feedback for setting the bar higher during community calls and in discussion here. Again, the draft issue actually upped the value to 33% instead of 20%, indicating at least 1/3rd of the staked LPT would have to participate in order for a poll to be valid.

Would love to get to a 50% quorum target eventually, and I hear the points about starting with an initially high bar because it is hard to move things later, but the counter to that is that:

1) the protocol doesn't yet have incentives for voting participation 2) nor does it have 2 years of behavioral expectation amongst network participants that they're supposed to show up to vote as part of their workflow

Would be great to use governance to add incentives for voting (such as requiring it in order to be eligible for the next round's rewards for example), but until those are there the quorum being all the way up to 50 seems like it will create difficult circumstances to even begin to use an open governance process to get the ball rolling.

I also don't think a more conservative quorum value leads to lower voter turnout. If someone cares about a contentious issue in the future of Livepeer, they have an even greater incentive to show up and vote, as they know their vote could count for more of the total turnout with a lower quorum than it would with a very high quorum. Effectively for those that care about governance, their votes could matter more.

yondonfu commented 4 years ago

Just to make sure that everyone is aware of the updates to the original proposal in the recently created draft LIP:

criticaltv commented 4 years ago

So, QUORUM will be 33.33 and THRESHOLD 50%. Right?

So, to begin it can be possible for a motion to be passed with e.g.

But a motion would not pass if:

because Quorum wouldn't be met. Is that right?

For Against Turnout Result
16.67 16.66 33.33 Vote Carried
16.67 16.65 33.32 NOT Carried
25.00 8.33 33.33 Vote Carried
25.00 8.32 33.32 NOT Carried
33.32 0.01 33.33 Vote Carried
33.32 0.00 33.32 NOT Carried
dob commented 4 years ago

That interpretation is correct according to the outlined definitions and criteria.

So now I think I understand the counter proposal better. Perhaps I was caught up on the 50% number more-so than the spirit: using 33% as the Quorum under the adjusted definition, and 50% as the Threshold would mean that any vote that reached 33% yes votes, without being outweighed by no votes, would pass - whether it was 33% vs 0, or 33% vs 32%.

What do others think about the two definitions?

A) The required % of stake that participates in the vote for it to be considered valid be executed.
B) The required % of stake that must vote in favor of the proposal for it to be passable.

This still leaves open the initial value for quorum, which was proposed as 33% (up from 20%), and counterproposed at 50% under definition B.

yondonfu commented 4 years ago

I lean towards keeping the current definition of quorum as:

"The minimum percentage of stake that needs to vote in a poll in order for the poll result to be considered valid"

because it matches the standard definition of quorum in a business/governance context [1].

[1] This comment in a thread about Aragon's definition of quorum makes the good point that quorum in a distributed computing context does mean the minimum number of approval votes for an action to be performed. That being said, I think using the standard definition of quorum in a business/governance context makes sense here.

kyriediculous commented 4 years ago

I feel like the current definition is most in line with how it is defined in dictionaries (ie voter turnout).

Generally speaking I think if there's standard definitions for terminologies we should stick to those definitions. Otherwise it will make discussing this topic harder as new entrants first need to understand the definitions used.

gavinly commented 4 years ago

Cosmos Hub has a 'no-with-veto' option. This enables 33.4% of participating voting power to fail a proposal, even if more than 50% approve. I think the idea is to prevent a tyranny of the majority and the ability to express a strong preference against a proposal. For reference, see these criteria.

Another thing perhaps worth considering is adaptive quorum biasing, which could require a heavier 'yes' threshold to pass a proposal the lower the vote-weight turnout. Polkadot and Kusama use this. I know simplicity is important, but this sort of scheme could enable a lower vote-weight turnout to be considered valid, provided that the 'yes' vote is substantially more than a simple majority.

dob commented 4 years ago

@gavinly on "no-with-veto" and "adaptive quorum biasing"...

These both sounds like really useful ideas in theory, but also as you point out, raise the complexity and barriers to understanding how governance works initially. Especially getting the AQB params right and being able to project whether something will pass or not based on current voting patterns.

Maybe taking the no-with-veto independently as it is a little more straightforward...do you think this is a good candidate for one of the initial proposals? This way the community can weigh it independently through the LIP process, debate it, vote on it through the polling app, and enact it if it seems like a good idea for Livepeer? Again, this way it could be community designed, rather than bundled in as another debatable, arbitrary decision baked into the initial simple designs?

gavinly commented 4 years ago

I like the idea of using the polling process to include an element of community design. However, I'm skeptical that a seemingly-minor addition like a 'no-with-veto' option would attract more than 33% of the LPT supply for poll participation. Thoughts?

dob commented 4 years ago

However, I'm skeptical that a seemingly-minor addition like a 'no-with-veto' option would attract more than 33% of the LPT supply for poll participation. Thoughts?

Good question. It's really hard for me to predict whether it will be difficult or easy to get 33% for a small change like this. On the "it would be easy" side, is the recognition that it only takes a few of the active orchestrators who carry a lot of stake weight to participate, and there aren't likely to be THAT MANY active polls to overwhelm anyone. On the "it would be difficult side", if this doesn't feel like a major network economic upgrade, is it possible to even get the word out and encourage participation without a participation incentive (or non-participation penalty)?

gavinly commented 4 years ago

Brainstorming here, so feel free to ignore.

TL;DR

  1. Reduce inflationary rewards temporarily for non-voting orchestrators to increase the likelihood of voting participation.
  2. Have a kind of 'spam' vote option to use if a voter thinks that a poll is spam.

Opportunity cost for failing to vote

What if the inflationary rewards of an orchestrator were a factor of poll participation? Heavy question, I know. More responsibility for orchestrators, and we can only lose with a mechanism like this.

Scenario: of the last 100 polls, I miss one, then my orchestrator earns 99% inflationary rewards for x number of rounds.

There's an incentive for orchestrators to blindly abstain, so what's the value? Orchestrators would be incentivized to monitor for polls and to act. Even if participants simply abstain, I imagine that there would be a net increase in participation. BTW, is 'abstain' even a poll option?

On the flip side, I could see this mechanism being used as a griefing attack. At $0.57 per LPT and 200 LPT per poll, it's only $114 to bother all of the orchestrators. If such a griefing attack takes place, we could make a proposal to increase the deposit amount.

Vote option to use if a voter thinks that a poll is spam

Similar to the 'no-with-veto' suggestion, a vote option like 'spam' could do a few things: 1) Cancel a poll prematurely if 33% of LPT votes 'spam' 2) Increment a parameter that will eventually raise the deposit amount for proposals automatically

The 'spam' vote would count as a 'no' vote. The idea here is to reduce the attention that spam proposals get by ending them prematurely, and also to eventually start to increase the cost of a poll if too many spam proposals are created.

gavinly commented 4 years ago

However, I'm skeptical that a seemingly-minor addition like a 'no-with-veto' option would attract more than 33% of the LPT supply for poll participation. Thoughts?

Good question. It's really hard for me to predict whether it will be difficult or easy to get 33% for a small change like this. On the "it would be easy" side, is the recognition that it only takes a few of the active orchestrators who carry a lot of stake weight to participate, and there aren't likely to be THAT MANY active polls to overwhelm anyone. On the "it would be difficult side", if this doesn't feel like a major network economic upgrade, is it possible to even get the word out and encourage participation without a participation incentive (or non-participation penalty)?

Without a built-in (dis)incentive mechanism, I think stakeholders would have to be targeted individually to participate so that there isn't a bystander effect. I think that this sort of relationship lends itself to becoming a power broker.

yondonfu commented 4 years ago

@gavinly

However, I'm skeptical that a seemingly-minor addition like a 'no-with-veto' option would attract more than 33% of the LPT supply for poll participation.

One way to try to improve the chances of quorum being reached could be to propose a "no-with-veto" option with other governance changes/improvements either in the same LIP or in multiple LIPs that are bundled into a parent LIP. LIP-15 notes that LIPs can be a part of a parent LIP so that a poll for the parent LIP considers all individual LIPs referenced. This could reduce the burden placed on tokenholders since they wouldn't need to vote in multiple polls for smaller LIPs and they would just need to vote in a single poll for a set of LIPs that constitute a "major" governance change.

What if the inflationary rewards of an orchestrator were a factor of poll participation?

Would love to explore the incentive design space for orchestrator poll participation and I think limiting inflationary rewards is an interesting alternative to slashing. But, it is worth noting that the polling system described in this LIP has a minimal on-chain footprint with all of the tallying logic pushed off-chain for the following reasons:

Implementing rewards/penalties for poll participation would increase the on-chain footprint of the polling system and require changes to the core protocol contracts. At this early stage, I'm interested in experimenting with these polls without introducing changes to the core protocol contracts. My thinking has been that these designs could be introduced in the 3rd milestone of the governance roadmap which will introduce a binding on-chain voting system. My suggestion is to continue the design brainstorm for this topic in a separate thread that could lead to its own LIP - what do you think?

BTW, is 'abstain' even a poll option?

It isn't an option right now.

I can see the value of having it as an option though so we can distinguish between accounts that did not participate at all and accounts that participated, but explicitly expressed that they would be fine with any outcome. I'd support adding this as an option.

I'm unsure about adding no-with-veto as a choice immediately due to a concern about communicating to voters why one should vote no vs. no-with-veto and it introduces another parameter (veto threshold) that needs to be arbitrarily set. But, in the interest of reducing the friction of potentially adding the choice (or others) in the future, I propose the following changes to the LIP:

This is the current contract interface:

contract Poll {        
    // Emitted when an account submits a yes vote
    // This event can be indexed to tally all yes votes
    event Yes(address indexed voter);
    // Emitted when an account submits a no vote
    // This event can be indexed to tally all no votes
    event No(address indexed voter);

    /**
     * @dev Vote yes for the poll's proposal.
     */
    function yes() external;

    /**
     * @dev Vote no for the poll's proposal.
     */
    function no() external;
}

This would be the updated contract interface:

contract Poll {        
    event Vote(address indexed voter, uint256 choiceID)

    /**
     * @dev Vote for a poll's proposal
     * @param _choiceID ID of the choice being voted for
     */
     function vote(uint256 _choiceID) external;
}

By making this update to the contract, the addition of additional vote choices (i.e. no-with-veto) in the future would be much simpler. No changes on-chain would be required. The only changes required would be updating the UI and the off-chain indexer to be aware of the new vote choices.

criticaltv commented 4 years ago

So, let's say we stick with the "standard definition of quorum in a business/governance context" per @yondonfu suggestion.

And let's say we start that at the arbitrary number of 33.33%, and see how things go. This means that 16.67% (i.e. a couple of Livepeer whales) can carry a motion, assuming 16.66% also turn up and oppose it.

Now, if we are ever minded to tighten things up, to "raise the bar" in terms of participation, we might say, increase quorum value to 50%. This would mean that a vote could technically pass with only 25.1% of all voting weight saying YES to it, again, as long as 24.9% also turn up and oppose the motion (or abstain, or whatever).

Perhaps we tighten it further, and have quorum as 80%. This is better, as it requires at least 40.1% to say YES in order for a vote to pass... again, as long as 39.9% participate and vote NO / Abstain.

But 80% might be a very tough ask, and even then, the motion can carry with much less than half the total voting weight. It still doesn't sound so "tight".

The idea of 100% is obviously off the table. This means that by using the proposed construct / definition, we can't ever set the votes to require that strictly >50% vote YES in order for vote to pass. This feels wrong to me.

Here's a reminder for the alternative, which isn't an alternative definition for the same thing ("quorum"), it's an alternative "thing" with an different name altogether ("minimum acceptance quorum"):

"Minimum acceptance quorum": minimum % of all token supply that needs to approve in order for the voting to be executed.

I still support using this alternative parameter. It would allow for the desirable option in future of setting the quorum up to 40% or 50%, and being able to pass motions safe in the knowledge that there really is a majority support.

Consider also, that with the alternative definition, the "minimum acceptance quorum" can never be higher than the "threshold". So the highest the bar could be raised to would be 50%, unless you also raised the threshold. And in that case, we would be able to pass votes with 50.1% saying yes, and nobody else caring to say no.

And on a final note, I don't agree that basing onchain governance mainly on models defined in corporate boardrooms which assume some level of physically co-located in-person voting, is necessarily the most appropriate basis for an onchain governance model in a more socially distanced world.

nelsorya commented 4 years ago

Lots of interesting ideas being discussed here and I'd love to talk through and expand on some of these on the next community topic call.

As for the core Quorum Parameter decision I agree with QUORUM of 33.33% and THRESHOLD of 50% initially. I think then as everyone gets comfortable with the LIP process we can gradually increase to 50% over time

kyriediculous commented 4 years ago

My issue with the current values of the quorum (or definition if you look at it from @chrishobcroft 's perspective) is that a vote with more no votes than yes votes can still be considered passing while there is a clear signal that it shouldn't have.

This is due to the fact that THRESHOLD only accounts for "yes" votes.

THRESHOLD: The minimum percentage of voting stake that needs to vote yes in a poll in order for the poll result to be considered a signal to accept the proposal.

I think this should be

THRESHOLD: The minimum percentage of voting stake that needs to vote for or against a poll in order for the poll result to be considered an acceptable signal.

Regarding a poll interface that supports multiple options, I would be very okay with this.

I would just make use of an enumerated field just because this officially encapsulates the IDs and their respective values within the smart contract (at a negligible gas cost

contract Poll {        
    event Vote(address indexed voter, Choice choice);
    enum Choice{ Yes, No, Abstain }

   function vote(Choice _choice) external pure isActive {
       emit Vote(msg.sender, _choice);
   }
}
criticaltv commented 4 years ago

a vote with more no votes than yes votes can still be considered passing

How so? @kyriediculous

kyriediculous commented 4 years ago

Based on the current definitions the amount of votes against is not taken into account. Given the current values one only needs 16.65% of stake to vote yes, but the remaining 83.35% can still vote no.

criticaltv commented 4 years ago

I don't think that's right, @kyriediculous

kyriediculous commented 4 years ago

ah no you are right

I actually do agree though that just saying 50%+1 vote of active stake needs to vote yes would be a better construct then we don't need to have discussions about sensible QUORUM and THRESHOLD values either.

I don't think a minority should ever be able to pass a vote actually, one should actively try to gather more support instead then.

dob commented 4 years ago

I don't think a minority <50% threshold value would be likely to be enacted or make much sense, but I could see the threshold value being higher than 50%. For example 66%, indicating that at least 2/3rds of the votes were in favor (and therefore 1/3rd of the votes could veto). Not suggesting this, but just pointing out the example of where alternate threshold values could be considered.

In reality, the Adaptive Quorum Biasing concept seems to be a good theoretical solution to both this, and the alternate quorum definition suggested above. However as it is so complex in implementation and the mental overhead to understand it to participate effectively, I'd recommend leaving it to a separate future discussion and LIP as to whether and how to implement it.

kyriediculous commented 4 years ago

I don't think a minority <50% threshold value would be likely to be enacted or make much sense

Totally agree, but in theory a quorum of 34% and threshhold of 50.1% yes votes would constitute a passing vote despite only 17% of total staked LPT actually voicing support. Should we act on such results or ignore them?

If we decide within social rules to not act upon these close call results then it doesn't make sense to have a mechanism that even allows these votes to pass in the first place in my opinion.

Also I thought about the "abstain" option some more and I don't think it is actually worth implementing this change as of right now for the simple fact that no one will ever vote abstain because there is no incentive to do so (it costs gas and it has the same effect as not voting). We can reconsider this if/when participation incentives (or disincentives for not participating) are on the table and if a "no-with-veto" option becomes a discussion point.

dob commented 4 years ago

Should we act on such results or ignore them?

We would act on them, because they passed both the quorum of 1/3rd and the threshold of 50% majority.

On Wed, Apr 15, 2020 at 11:18 AM Nico Vergauwen notifications@github.com wrote:

I don't think a minority <50% threshold value would be likely to be enacted or make much sense

Totally agree, but in theory a quorum of 34% and threshhold of 50.1% yes votes would constitute a passing vote despite only 17% of total staked LPT actually voicing support. Should we act on such results or ignore them?

If we decide within social rules to not act upon these close call results then it doesn't make sense to have a mechanism that even allows these votes to pass in the first place in my opinion.

Also I thought about the "abstain" option some more and I don't think it is actually worth implementing this change as of right now for the simple fact that no one will ever vote abstain because there is no incentive to do so. We can reconsider this if/when participation incentives (or disincentives for not participating) are on the table.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/livepeer/LIPs/issues/16#issuecomment-614102057, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACRFJP7FYB7HJQWRPMJP3RMXF3FANCNFSM4LS4C6BQ .

kyriediculous commented 4 years ago

If we should act on those then I don't think we should ever put a quorum lower than 50%

The system shouldn't be allowed to be hijacked by 5 orchestrators, although you could make the argument that the remaining Os seem to not care if they do not cast their vote.

But overall there are very little to none real world examples where a less than 20% minority could theoretically pass a vote. Elections is always 50% , voting on legislation sometimes requires a 2/3rd majority , shareholder voting is always 50%+1, etc.

dob commented 4 years ago

Hmm, do you really think "Hijacked" is the right way to describe the scenario where only the top 5 orchestrators vote on a contentious proposal resulting in a 17%-16% split? If the results of a poll look like they're shaping up like that, then the entire community (including the other 95 active orchestrators) have the ability to weigh in, and it doesn't take much to swing it from a yes to a no. Essentially every vote + override counts.

It's totally valid to have the opinion that quorum should be at least 50%, but I'm not sure it's correct to characterize a 33% quorum. as leading to clear opportunity. to hijack a system.

On Wed, Apr 15, 2020 at 11:23 AM Nico Vergauwen notifications@github.com wrote:

If we should act on those then I don't think we should ever put a quorum lower than 50%

The system should be allowed to be hijacked by 5 orchestrators.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/livepeer/LIPs/issues/16#issuecomment-614105510, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACRFJ7KM3Q4NMYCM4EA4DRMXGQZANCNFSM4LS4C6BQ .

criticaltv commented 4 years ago

I agree with @kyriediculous.

However unlikely it might be, merely the technical possibility that 16.67% of all voting weight could pass a motion is too prone to hi-jack by a minority.

This is especially true, given the known concentration of stake delegated by a few (e.g. 2) individuals, and delegated to a few (e.g. 5) orchestrators.

criticaltv commented 4 years ago

For me, the nub of this is whether to use pre-existing constructs for

I think we're building a distributed system here, not a corporation.

Specifically, for me, the proposed construct, using the "traditional" concept of a quorum, and using the proposed initial figures, is:

I still advocate using the MINIMUM ACCEPTANCE QUORUM (instead of QUORUM), and making it e.g. 25%, and SUPPORT REQUIRED (instead of the ambiguously titled THRESHOLD) of e.g. 50%... here are the definitions again:

This would:

  1. Still require more YES than NO for a vote to pass (e.g. 25% YES vs. 26% NO would not pass)

  2. Require at least 25% of total voting weight to accept a motion (i.e. vote YES) in order for it to pass (up from 16.7%)

  3. Allow us to "tighten things up" in "sensible" ways in future, e.g. make it so that votes

    • can't pass with <50% of total voting weight accepting, AND
    • can pass with <100% participation

BOTH of these would not be possible using current construct.

  1. Allow us to "loosen things up" without unduly increasing risk of hijack.

The mere existence of the definition of a Quorum in a distributed computing context, for me, supports this approach. Isn't this precisely what we are doing here? Building governance for a distributed computing system?

Let's not recreate legacy corporate boardroom governance for something which is not a corporate boardroom.

kyriediculous commented 4 years ago

I think "hijacking" is definitely the right term (It's equivalent to a shareholder proxy fight) and I wouldn't even call it very unlikely. Here's why I think that is:

  1. The top 5 orchestrators own more than 35% of delegated stake (no one knows how much of that is really delegated)
  2. Delegators are less likely to participate in governance if they are already not very actively participating in the protocol.
  3. The need for a quorum assumes not everyone will vote
  4. Due to point 1 it is unable to tell collusion is happening and it's very hard to swing the vote against it

Let's assume a maximum of 70% of stake will actively participate in voting at any point in time (the other 30% lost their keys , doesn't care, or worse) , well the top 5 orchestrators can now collude against the majority and they will if the economic incentive is there for them to do so. This number gets worse and will only require the top 2 O's to collude if voter turnout is 33%.

After further thought and reading the distributed computing definition of quorum linked by @criticaltv I actually think it is sensible if this is already a standard definition within the distributed computing domain.

Furthermore I still rest my case that a small minority should never be allowed to pass a vote (even if this would be unlikely), even if the voter turnout is low. If the concern is tyranny of the majority then other measures need to be taken such as a no-with-veto option (at a cost) or not only considering stake-weight (concurrent majority). I would try to avoid tyranny of a minority over tyranny of the majority.

I think the approach being taken in this LIP to avoid bad outcomes is not proactive/conservative enough. The numbers have no precedent in any traditional voting system. The assumption is that this can be tweaked later but what is there to tweak if everyone has lost faith in the governance system due to perceived (or real) unfairness. We are setting precedent for a binding voting system, this should not be threaded lightly but rather with caution. Even when not altering the definitions we should considering starting with a higher QUORUM and lowering it when necessary (I mean it's a social construct which we are discussing over now, it can be re-discussed after deployment as well). Then again in a non-trusted environment the quorum should realistically never be less than simple majority in my opinion but I have already voiced that plenty.

Numbers/schemes that have precedent:

I actually like supermajority in this scenario if we think of other ways to tackle the tyranny of the majority or the status quo in future iterations (I'd prefer a concurrent majority rather than no-with-veto). Which is what adaptive quorum biasing does for polkadot. They depart from a supermajority to begin with, with following additions:

Specifically we have a council which, in the model of a board of directors, is a group of individuals delegated by stakeholders to help determine what happens when there is no commanding majority of stake in favour or against a proposal.

We also introduce a concept "Adaptive Quorum Biasing", which functions as a lever that the council can use to alter the effective supermajority required to make it easier or more difficult for a proposal to pass in the case that there is no clear majority of voting power backing it or against it.

Finally, we introduce a twin-mechanism "lock-vote multiplying" and "delayed vote enactment", which works orthogonally to stake-weighted voting to ensure that the more exposure to a decision that a voter is willing to take, the more their vote is counted.

Let's not recreate legacy corporate boardroom governance for something which is not a corporate boardroom.

This is where I disagree, there's lots to be learnt from traditional voting systems and there are some very good concepts which we shouldn't reinvent the wheel for. I would also say there are similarities between this and a boardroom since we are all casting our vote for what we think will result in optimal cashflow (or at least that's the idea , ignoring self-interest for a bit).

On tyranny of the majority:

It is a paradox. You design a system within certain rules which causes limitations, but these limitations are the very nature of the system. Trying to alter the limitations changes the system and all your previous guarantees built into the system now disappear as well. You can combat the issue (eg. elections, separation of powers, 2nd amendment, ...) but you can not circumvent it entirely. There are only two alternatives: fraction (cfr fork) or tyranny of a minority.

yondonfu commented 4 years ago

24 updates the spec in the LIP such that the poll contract accepts a choiceID when a vote is submitted with the valid list of choiceIDs defined by the off-chain indexer. This update makes it easier for additional voting choices to be added in the future if needed without requiring a contract update.

(Will follow up with my thoughts regarding quorum separately).

jbrukh commented 4 years ago

Just a few comments, none of which I feel super strongly about:

js0n commented 4 years ago

Random question: if slashing is being considered as part of this extension to the protocol, what's an appropriate way to deal with poll creators spamming the protocol with polls which carry the threat of slashing or some kind of non-participation penalty?

Non-participatory penalties ostensibly incentivizes orchestrators to automate participation.

In absence of an abstain option, is there any concern that polls carrying non-participation penalties could be used as an attack vector by a malicious orchestrator to tamper with stake distribution or introduce proposals that wouldn't otherwise pass human scrutiny.

yondonfu commented 4 years ago

Note: The following is an editorial comment

Given that there is still some ongoing debate in this discussion thread, the Last Call period for LIP-16 will be extended for 1 week. While there is some disagreement around the issues under debate, there do not appear to be major objections that should revert LIP-16 back to Draft status so the Last Call period is being extended instead.

yondonfu commented 4 years ago

While there are a couple of suggestions for improvements to the polling system that are worth discussing separately, I believe the current disagreement in this thread centers largely around the following issues:

I'll focus on the first issue in this comment because I think it is important to address this first so that discussion around the second issue can be free of terminology confusion.

Requiring a quorum or requiring a minimum acceptance quorum

I agree with the following point made by @jbrukh

The quorum structures and language is always really confusing and nuanced across systems. It is hard to grasp even for researchers and implementors, so I recommend we make this as simple as possible to communicate.

I think the priority for LIP-16 should be to establish a basic system that is as easy to understand as possible. So, I believe that standard terminology and definitions from existing literature/fields of study should be used to minimize the amount of new terminology and definitions that need to be explained to participants. The more familiar and accessible the basic system is, the better chance it has to be accepted by the community and an aligned community is critical for the evolution of the system since this is just the first iteration.

While minimum acceptance quorum is a term used in Aragon and also is used in a distributed computing context, it is far less commonly used relative to quorum which is not only used in social choice/voting literature, but also in most governance structures (and we're talking about a digital governance structure here!).

To summarize, my stance on this issue is to:

dob commented 4 years ago

With regards to the initial parameter value of quorum, the current proposal is 33% but there are clear points above from multiple people who have expressed that they wish to see a minimum quorum value of 50%, to ensure that at least half of the active stake participates in a governance decision in order for it to be valid. Before weighing in further on this, I want to pose a question...

Is it possible that a quorum with a bar that high actually centralizes power and renders the opportunity to participate in governance less accessible than a lower quorum value, due to the political processes likely required to ensure such high participation in the first place in the absence of initial in-protocol incentives/penalties for participation in voting?

How could this be the case? I think the answer may lie in something mentioned by @gavinly

Without a built-in (dis)incentive mechanism, I think stakeholders would have to be targeted individually to participate so that there isn't a bystander effect. I think that this sort of relationship lends itself to becoming a power broker.

If it's a tremendous challenge to even reach quorum, then there will be tremendous social effort required to get engagement on issues big and small. And the focal points of influence in the system will have the most ability to coordinate voting amongst those more apathetic in order to ensure that quorum is reached. If some people are apathetic on an issue in the first place, they may be likely just to get a recommendation on a vote from the person doing the coordinating. This seems like a central source of power. On the other hand if no one puts in this effort for coordination, then its unlikely votes will reach quorum, and the default-state is that polls just sit there without much attention.

Contrast this to a lower quorum value, where every vote can counts a little bit more early on. Polls reach quorum quicker, and it is clear that if others don't weigh in then changes will occur. All the sudden it becomes more accessible and important to pay attention, to vote, to participate. Sure, there may still be lobbying and coordinating on a campaign, but everyone has a lot on the line because the status quo is aways at risk.

I guess the debate here is what is more risky, centralizing in the form of a power broker politician and lobbying effort, or centralizing in the form of a few O's being able to reach quorum on their own if no one else cares about weighing in on the issue?

kyriediculous commented 4 years ago

it is far less commonly used relative to quorum which is not only used in social choice/voting literature, but also in most governance structures (and we're talking about a digital governance structure here!).

I agree, but keep in mind that when designing for simplicity using a minimum acceptance quorum would result in a single parameter (from my understanding) instead of two, QUORUM and THRESHOLD , I believe the relation between the two to leads to confusion most often. So having a single parameter could actually simplify the system. I don't believe renaming to QUOTA fixes that.

Is it possible that a quorum with a bar that high actually centralizes power and renders the opportunity to participate in governance less accessible than a lower quorum value

That depends on how much elasticity there is in the quorum value will increasing the quorum from 33% to 50% result in much more of a bystander effect.

A too low quorum value could also have negative "too small to make a difference" effects.

I also think there are a few assumptions being made when talking about possible side-effects while the ownership of the top 5 O's over the network relatively to the quorum and threshold values is something we can actually measure right now and base our parameters on.

I believe we need to settle on these two discussion points:

I am not strongly opinionated here since this system is non-binding and just an intermediary step, however I feel like my opinion can be best summarised as "minimum acceptance quorum of 50% + 1 LPTU"

By not strongly opinionated I mean that I'm fine with the current proposal as well since a compromise has already been made towards the initial QUORUM value but I feel like the alternative shouldn't be simply discarded yet.

chrishobcroft commented 4 years ago

Consensus Point

I also agree that we should make this as simple as possible to communicate.

Equally Simple

I propose however, that these 2 concepts are equally simple to communicate, irrespective of how each is labelled:

  1. minimum percentage that needs to vote in a poll in order for a result to be executed

  2. minimum percentage that needs to vote yes in a poll in order for a result to be executed

I also propose it to be presumptuous and counterproductive to be proposing an "initial parameter value" for either option before a decision is made on which to use (except perhaps for illustrative purposes only).

Individual Biases

We each believe, fundamentally, that one of these concepts is inherently more simple to understand than another.

I propose that this due to individuals' biases built from prior experiences of participating in democratic governance systems, by which I mean any kind of democratic decision-making system, including:

We are "the 1%"

I would hazard a guess that all contributors to this thread, and most who are reading it, have experience participating in at least one, if not all of these types of democratic governance systems.

I'm not aware of a well-defined, well-communicated concept of a "quorum" in any of the above contexts, but I may be mistaken.

However...

The concepts of "quorum" is very well defined in this context, and fits most closely to option 1.

There are multiple definitions of quorum here, as projects find the best fit for them

Quorum is so well defined in this context that it has it's own Wikipedia page! It is most closely associated with option 2.

I therefore propose that our biases about which option is simpler to communicate are heavily influenced by our individual understanding, based on our individual experiences.

I also propose that this proposal is heavily biased towards US corporate governance, influenced by individuals whose primary experience of participating in such sophisticated governance systems is from the inside of a private boardroom.

What about "the other 99%"?

I'm not one of them, but this is what I have been learning about them:

44% of the world's population don't live in a democratic nation state. Data Point: In 2015, 3.25 billion people from 7.35 billion were deemed to not be living a Democracy (source: World Population by Political Regime from ourworldindata.org).

So that's 3.25 billion who have never participated in a national democratic system. I wonder whether the concept of a quorum even exists in their minds.

297 million people (approx 33%) living in "the world's largest democracy" did not participate in the 2019 Indian general election. Turnout was reported as 614 million of 912 million (source Wikipedia: 2019 Indian general election.

But nobody needs a pre-conceived idea of what quorum means in government elections... I don't believe a national election needs to make quorum to be considered valid?

Then it's only really the "Corporate Types", "The Board", "DAO Participants", the "voting shareholders", and the "Committee Members" and Bureaucrats who ever need to consider what a quorum is. And many of them likely just vote YES or NO. Maybe some of them know about quorum. Maybe.

So, I propose that it's really probably only a small minority who have a well-formed view about what a "quorum" means, and even fewer who can entertain the idea of there being multiple viable options. Which means there is space to break with convention, and explore something fit for purpose.

Wrapping up...

They are both equally simple to understand - both for some of the 1%, who can open their minds to new ways, and for the 99% who are learning such concepts for the first time.

The choice, for me, comes down to whether we are building a governance system for:

a) a private company incorporated in the United States of America, run by voting equity holders in a corporate governance, familiar with a concept of quorum, and seeking to engage other people who think in the same way as they do,

or

b) open-source public permissionless distributed systems, run by free-acting individuals under the influence of the crypto-economics, who will inevitably think very different from ourselves.

Personally, I want b), and I have no interest in building a) but I will always keep an open mind to those who are different from myself, as I aim to contribute to a governance mechanism which can be adopted by 7.8 billion, instead of an extension of "Corporate America".

Conclusion

So, I don't have a vote (yet!), but if i did, I would vote to design and build a system around the concept of a quorum being defined as:

_2. minimum percentage that needs to vote yes in a poll in order for a result to be executed_

Because I believe it is better suited to the use case, and also because of the greater flexibility it affords us with setting the parameters, explained by @criticaltv

And Finally...

The only difference between the two definitions, is that one contains the word "yes" and the other one doesn't.

My completely unsubstantiated theory is that the one with "yes" in it, will result in a process which focuses on the positives of change, as an inevitable and natural force in this universe :)

chrishobcroft commented 4 years ago

We are also yet to hear anything from @ericxtang @f1l1b0x @adamsoffer @j0sh @darkdarkdragon @angyangie @iameli @ya7ya @ppunktw @chris-remus @r

I would love to know what they're all thinking :)

dob commented 4 years ago

Good questions from @js0n

Random question: if slashing is being considered as part of this extension to the protocol, what's an appropriate way to deal with poll creators spamming the protocol with polls which carry the threat of slashing or some kind of non-participation penalty?

First of all, I'll note that no slashing is being proposed as part of this initial proposal. The mechanism, and incentives, aligned with requiring participation would be designed and proposed separately, at which point answers to your question would be made clear by the proposal. Some ideas though...

Non-participatory penalties ostensibly incentivizes orchestrators to automate participation.

Good point. Automating "Abstain" would be a perfectly rational course of action here that wouldn't help the network. Would be good to discuss solutions around this in another thread when the designs here are actually being proposed.

yondonfu commented 4 years ago

@kyriediculous

but keep in mind that when designing for simplicity using a minimum acceptance quorum would result in a single parameter (from my understanding) instead of two

I think using minimum acceptance quorum as the sole parameter would only work if the minimum acceptance quorum is > 50%. Otherwise, you could end up with a scenario where the minimum acceptance quorum is met, but the majority of stake shows up and votes no. For example, suppose the minimum acceptance quorum is 30% and it is the sole parameter. Then, if 30% of stake votes yes and 70% of stake votes no the proposal would be accepted. I'm guessing that most people in this thread would prefer to avoid that outcome.

The minimum acceptance quorum should be set based on the realistic turn out that can be expected/targeted so there should be flexibility in at this early stage for it to be lower than 50% if needed. In order to support this flexibility while also avoiding the outcome described above, we'd also need something like a quota parameter that requires a % of stake that shows up to vote yes. And as a result, we would end up with 2 parameters again.

@chrishobcroft

The choice, for me, comes down to whether we are building a governance system for:

The remainder of that statement notes that using a familiar concept of quorum means that the governance system is being built to match existing traditional systems. There is some truth to this, but I don't think this is quite correct. The motivation behind using familiar concepts it to use familiarity to help early participants to understand the system and researchers to analyze /help build the system. However, leveraging familiarity early on does not mean the system needs to exactly match traditional systems medium/long term. Leveraging familiarity early on is simply a way to kick start the evolution process of the system.

Because I believe it is better suited to the use case, and also because of the greater flexibility it affords us with setting the parameters

I'll restate what I believe is your main point supporting a minimum acceptance quorum in this comment in my own words just to make sure that I understand and address it properly.

Using a minimum acceptance quorum allows us to tighten things up in a sensible way in the future by requiring > 50% of stake to vote yes without requiring 100% of stake to show up.

First, I'll acknowledge that in order to require > 50% of stake to vote yes with a quorum + quota based system we would indeed need to set the quorum to 100%. This is a downside of using a quorum + quota.

However, requiring > 50% of stake to vote yes using a minimum acceptance quorum implies that > 50% of stake shows up to a poll. At this early stage, we have no idea what % of stake to expect to show up to polls - 20%, 30%, 35%? Furthermore, we don't know if it will ever be realistic for > 50% of stake to show up to a poll. So I don't think we should design for a goal that may or may not be realistic.

In this setting, in the absence of baked in participation incentives, the best that we can do is attempt to understand what a realistic % of stake we can expect to show up to a poll. As we go through this process, why reinvent the wheel? There is a large body of quorum based systems both in the crypto and non-crypto worlds that we can learn from. Using a quorum is useful because the rules for accepting/rejecting a proposal are defined relative to the current quorum which reflects the current expectations around poll turn out. As our expectations for poll turn out change given real world data the quorum can change as well (this can be a manual adjustment or a dynamic adjustment via an adaptive quorum adjustment algorithm mentioned earlier in this thread).

So, I don't have a vote (yet!), but if i did, I would vote to design and build a system

And you'll be able to vote and create polls very soon! After putting forth this initial version of the polling system you'll be able to propose and build consensus around any changes to the system that you feel strongly about. At that point if you feel strongly about using a minimum acceptance quorum then you can champion a LIP to put it forward to the community which will then use this polling system to express their preferences about the idea! And this proposal can even be informed by some real world data about how the initial quorum based system fares.

From my POV, it appears that most participants in the discussion thread thus far are ok with a quorum + quota as the starting point and do not see a particularly strong reason not to start with these parameters, but are open to alternate parameters and system designs that can be made if they are pushed forward after this basic system is established in a more community driven manner. So, my position is: let's focus on getting to a point where LIPs can be submitted and voted on by the community so that proposals such as using a minimum acceptance quorum can be considered using tools that give the broader community a voice in the matter even if they are not a part of the debate in this GH issue.

chrishobcroft commented 4 years ago

@kyriediculous

when designing for simplicity using a minimum acceptance quorum would result in a single parameter (from my understanding) instead of two

This isn't true. When using QUORUM defined as "minimum percentage that needs to vote yes in a poll in order for a result to be executed" you still need both parameters: QUORUM and QUOTA.

It is still necessary to define a QUOTA (e.g. of 50%) so that in cases where the QUOTA is set to less than 50% (e.g. 40%), then it makes it explicit that a vote can still be rejected if 40% vote YES but 41% vote NO.

I think it is fair to say that QUORUM become more "significant" as a parameter when defined as above, however it does not become so significant as to remove the need for QUOTA.