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.

chrishobcroft commented 4 years ago

First, can I request that we don't refer to either option as a "quorum + quota based system" as I find it confusing when all options under discussion involve a "quorum" and a "quota".

Personally, I will continue to refer to the two definitions that have been proposed for "quorum", which while subtlely different in words, result in fundamentally different mechanics and opportunities.

Definition 1: minimum % of all stake that needs to vote in a poll in order for a result to be executed Definition 2: minimum % of all stake that needs to vote yes in a poll in order for a result to be executed

Second, I want to share a goal: to eventually reach a situation where no changes can be made to Livepeer unless >50% of all stake vote YES (irrespective of how many vote NO or abstain).

I wouldn't attempt to achieve this day 1 - no way. This is more like a target for 2023, and I think would result in a powerful system, robustly secured by the owners.

I'm all for starting with the bar low and evolving as we go. But let's not limit how high we can set the bar in future by adopting structures designed for a different purpose, with known drawbacks.

Thirdly, I will restate my position, for the sake of clarity:

I propose we should define QUORUM as:

Definition 2: minimum % of all stake that needs to vote yes in a poll in order for a result to be executed

In this case, per the above comment, we also need a QUOTA.

I do not wish to propose any initial values for QUORUM or QUOTA. This is because I don't want to get into a subjective argument about whether the initial parameter value is too high or too low until perhaps we have agreed which definition to use for the parameters. I would sooner start with an arbitrary value and let it evolve democratically.

If I was pushed however, I would propose some numbers to illustrate an example:

But I would then support regular votes to increase QUORUM incrementally as we learn more about participation levels, with a stretch target of 50%, one day, in our wildest dreams.

And if we were to ever reach that point, I would then support efforts to push that bar yet higher, towards an ecosystem where we need even stronger consensus to evolve. I realise that this last point is maybe overly ambitious, but I want to aim high, and not be hamstrung by the known drawbacks of the design proposed above.

Fourth, in response to @yondonfu's points:

From my POV, it appears that most participants in the discussion thread thus far are ok with (Definition 1) as the starting point

From my POV, @yondonfu and @dob are fixed in their definitions and are tightly aligned (and let's face the fact that right now they are in ultimate control).

@kyriediculous and myself are on similar tracks which appear to be orthogonal to Yondon and Doug, but we are not so tightly aligned with each other.

The remainder (a vast majority) either don't have deep-seated experience or opinions either way, or don't want to disrupt the status quo, or are silent bystanders.

Also, I accept that my POV might be incomplete, as conversations may be happening outside of this forum.

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

Agreed! I believe that this is not only a downside, it is an excessively limiting basis upon which to design a system to govern Livepeer, especially when an equally simple and less restrictive alternative (Definition 2) exists, albeit less familiar to some.

This downside is likely tenable in the context of corporate / committee governance, where vote holders can be incentivised to participate, or where participation can be managed by proxy or delegation.

But I believe this downside is untenable in the context of Livepeer's hundreds of Orchestrator, thousands of delegators, and millions of token holders, without strong incentives to encourage participation from day 1, or well-defined systems to enable delegation.

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%?

Agreed! I am definitely not suggesting to initially require >50% of stake to vote YES. In fact, quite the opposite (see my restated position above). I also suggest that 20% is probably optimistic for the early days, let alone 30% or 35%, unless we can make the UX as easy as falling off a log.

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.

Agreed, we don't know! But I don't agree that we should make design decisions at this stage which preclude us from even being able to aim at such a goal.

I have proposed what I consider to be a desirable target end goal, a reasonable starting point, and a proposed route from start to end, as well as what to do when we get there - all based on Definition 2.

The best we can achieve using Definition 1 in the context of Livepeer is far less desirable IMHO, and is perhaps an even harder path to follow.

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.

My stance on this, is that whether we use Definition 1 or Definition 2 will not make any significant difference to an individual's understanding of how to navigate the mechanics of participation.

At a base level, individuals will be asked a YES / NO question, and perhaps they will answer if they have a view. How the votes are tallied and how those tallies are used to enact change is likely of secondary interest to most, compared to their ability to exercise their democratic voice.

What we do early on will very strongly influence the medium / long term. Which brings me back to the fundamental choice about whether we're building a corporation, or a distributed system.

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?

I agree that we need to learn as we go. None of us here are experts, and this has never been done before in this context.

However, I don't agree that using terminology defined in governance of distributed systems is "reinventing the wheel" when building governance for a distributed system :) It may be unfamiliar to some, but that shouldn't stop us from exploring it.

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).

I'm all for changing the value of a parameter, whether manually, or dynamically. I'm not pushing for a high value from the start, the opposite in fact.

But I am pushing for a base level concept to be defined differently from what you are proposing, in ways which I believe will allow us to reach higher.

By all means, let the value of the parameter fluctuate democratically, but let's not tie our own hands by using a core construct with known drawbacks.

At that point if you feel strongly about using (Definition 2) 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.

I'm already trying to champion this. And I'm intentionally expending the effort now, before the train pulls out of the station.

I do hope that changing the values of pre-defined parameters will be feasible down the line.

However, I fear that trying to change a core definition (even a single word) will be as hard as trying to change the wheels of the train while it's in motion.

It may even be easier to build a new train, on a parallel track, headed for a more distant destination, but this will unlikely have any legitimacy with passengers, because the permissioned few who make the onchain changes are driving the other train full steam ahead, on the way to a less ambitious end-of-the-line.

kyriediculous commented 4 years ago

Second, I want to share a goal: to eventually reach a situation where no changes can be made to Livepeer unless >50% of all stake vote YES (irrespective of how many vote NO or abstain).

I think this is a noble goal to have although I would change "stake" to "stakeholders" perhaps. It is unclear at this point whether a binding voting system in the future will consist out of only tokenholders or not.

It may even be easier to build a new train, on a parallel track, headed for a more distant destination, but this will unlikely have any legitimacy with passengers, because the permissioned few who make the onchain changes are driving the other train full steam ahead, on the way to a less ambitious end-of-the-line.

That leads me to my second point. Any design consideration in this milestone for a non-binding voting system is unlikely to be part of the end stop for Livepeer governance. It is a certainty that at one point the non-binding voting system train will stop and another train will take over as the draft proposal for an extensible governance contract (https://github.com/livepeer/LIPs/issues/25) lays out.

Yet any implementation of a binding voting system will still be subject to the outcome of an LIP process and its poll and the willingness of the core team (which has every incentive to maintain and capture network effect for the Livepeer network).

Before we reach that point however it is likely that we need to take considerations from earlier iterations of a non-binding voting system into account and improve on that before any stakeholder should feel comfortable about a poll to implement a binding voting system (which will be likely more contentious than a non binding voting system). When saying "we" this can be both the core team and the community and as @yondonfu mentioned improvements can happen through the LIP process. Therefore I think neither the initial values nor initial definitions are necessarily set in stone. While I do acknowledge that changing a definition is harder it can be overcome.

I think we should take every opportunity to learn and deploy a non-binding system sooner rather than later because that will get us farther than discussing the definitions and initial parameters.

So given the fact that

  1. This is a non-binding voting system
  2. Much of it is social convention
  3. It is not the end-goal or design
  4. It is likely to be short to medium term in terms of lifespan
  5. We already have potential champions for alternatives
  6. Bystander effect is less likely after the design phase (current)
  7. There is a clear path of moving to a binding voting system that still needs to be designed in the future laid out in https://github.com/livepeer/LIPs/issues/25

I feel like the best thing we can do is bite the bullet and move forward on a implementation and start learning as much as we can from it in the wild. Therefore I would be okay to move forward with the initial proposal and adjusted parameters. If we feel like adjustments need to be made we can do so under the form of an LIP and I'm very willing to explore the path of a minimum acceptance quorum down the line and gauge community acceptance for it through a proposal backed by data and observations we were able to do.

dob commented 4 years ago

Thanks @kyriediculous. I'd be on board with your ultimate conclusions. To quickly address a couple other points:

For the reasons mentioned above by @kyriediculous and @yondonfu, I'd suggest:

criticaltv commented 4 years ago

@dob

In reality, minimum acceptance quorum (MAQ) is actually an additional constraint beyond quorum and quota

This is not true.

  1. It is possible to operate with a quota, plus a requirement to only pass a quorum defined as "minimum % of all stake that needs to vote yes in a poll in order for a result to be executed" (or as you term is MAQ). In fact, any DAO created using Aragon's DAO framework works like this.

  2. It is indeed also possible to operate with a quota, plus a) a requirement to pass a quorum defined as "minimum % of all stake that needs to vote in a poll in order for a result to be executed" AND b) a requirement to pass a quorum defined as "minimum % of all stake that needs to vote yes in a poll in order for a result to be executed".

But it is misleading to say that the only way to use a "MAQ" is as an additional requirement to a traditional quorum.

You can also even have a voting system without requiring any concept of a quorum at all. This may actually be the simplest approach, if simplicity is what we're aiming at.

yondonfu commented 4 years ago

LIP-16 has just been assigned the Proposed status (via #26) which means the LIP is ready to be the subject of a poll.

Based on the latest discussion in this thread, it appears requiring a quorum vs. a minimum acceptance quorum (MAQ) is still the remaining point of disagreement. @chrishobcroft and @criticaltv are still in favor of requiring a MAQ instead of a quorum while the rest of the participants in the thread have either voiced support for requiring a quorum instead of a MAQ or have not explicitly expressed support for either option.

The participants in the thread that have voiced support for requiring a quorum instead of a MAQ have also addressed the suggestion of requiring a MAQ and have expressed that they do not believe that there is a substantial and clear enough benefit in requiring a MAQ at this stage to warrant requiring a MAQ instead of a quorum. While the goal is to address all concerns to the satisfaction of the objector that raised said concerns, this is not always possible if the rest of the group still disagrees with the suggested changes even after truly considering the suggestion and the objector remains steadfast in his/her support for the suggested changes. One of the goals of the polling system described in this LIP is to help resolve these types of situations.

Once the polling system is deployed then other stakeholders that are not active participants in this discussion thread will be able to explicitly voice their preferences around LIPs. However, at the moment, with the polling system not available for use yet, any decisions made around this LIP in this thread will be driven by a small group of individuals. So, making the polling system available for use will be crucial in opening up the decision making process outside of GH discussion threads. Until that point, the reality is that any update to this LIP will be decided upon by the participants in this thread without additional ways to capture/understand input from other community members.

Thus, assigning this LIP the Proposed status represents a step towards establishing said polling system. Then, the community will be able to accept/reject this LIP using the polling system itself. From that point, any additional changes (and changes to both the rules and parameters are expected given how basic this initial version is) will be able to be proposed using a system that is open to more people than just GH discussion participants.

yondonfu commented 4 years ago

LIP-16 has been assigned the Final status (via #29).