Skip to content
This repository has been archived by the owner on Jun 17, 2020. It is now read-only.

Economic Game Theory of Weighted Voting Systems #984

Open
allancto opened this issue Sep 27, 2018 · 10 comments
Open

Economic Game Theory of Weighted Voting Systems #984

allancto opened this issue Sep 27, 2018 · 10 comments

Comments

@allancto
Copy link

allancto commented Sep 27, 2018

Benefit to RChain

Voting of budgets within the existing Bounty and proposed RContributors system has direct impact on the financial health of our Cooperative. Sponsored research in this area may help us understand, design and implement attack resistant systems.

Detailed Description

Overview

  1. We (@allancto) describe the Trustmetric system as it was designed and evolved by Dan Connolly and others over the last year. Akin to Trustmetric, we describe Trusmetric EE, a similar system with nuanced differences.

  2. We (@allancto) have begun to investigate the avenues for mathematical modeling in this area. We’ve identified dGov18 as a potential venue for publishing applied research. We hope to include within this issue potential sponsorship of publishable articles, for instance with $5000 grants or prizes, assuming we are able to find qualified authors or teams.

  3. We (@caspar) propose a modelling approach which may be of utility in analyzing these weighted voting systems.

Summary: Trustmetric and Trustmetric EE

  • Both are weighted budget voting systems, budget B = sum (w[i] * b[i]).
  • Votes may be cast early and often, up until close of voting.
  • In TM voting weight is determined by separate “Certification/ Rating” voting seeded by TAC
  • In TMEE voting weight is determined TBD (representing experience and reputation within the community)
    • In TMEE voting closes later for higher weighted voters.
    • In TMEE voters may vote with any weight up to their maximim (useful for “guidance” voting)
    • In TMEE all members may vote

Summary: one proposed modelling approach

  • Players: P = 1:N; distributed as: 'normal' new members (nn = 1:i), 'bad' new members (bn = i:j), normal trusted members (nt = j:k), bad trusted members (bt = k:N-1), normal proposer (np = 0,1) or bad proposer (bp =0,1)
  • Utility functions (Motivations);
    z is first normalized to a scale of 0:10
    U(np) = 10 - |v-z|, with high-value state
    U(bp) = z, with high-value state
    U(nn) = 10 - |v-z|, with high/low-value state
    U(bn) = z, with high-value state
    U(nt) = 10 - |v-z|, with high/low-value state
    U(bt) = 10 - |v-z|, with low-value state
  • Parameters (P)
    Distributions of members with different motivation (represented by utility functions): amount of bad members.
    loosely determined by V2, following assumption 1&2, but specifics can be chosen.
    Distribution of states: how many people agree with the value of the proposer (high state is agree, low state is not agree)
  • Issues tested (I): dependent variables
    The ease with which the system is milked/scammed by new members
    What’s the threshold (how many bad actors are needed) for voting/proposing for pure monetary gain
    Measured by average voting behaviour/outcome in different situations
    The ease with which the system can be gamed by trusted members
    Bad trusted members undervalue work disproportionally to the rest
    Measured by average voting behaviour/outcome in different situations
    Democratic fairness of the system
    Existence of voting power for everyone (V2.3) or more people in trusted weighting (V2.2)
  • Hypotheses
    • The model shows that the preset of variables of the existing system is robust against I1 gaming in situation 1,3,5. Impairs the occurrence of S2, but is prone to I2 in situation 4.
    • V1 causes (theoretical) issues, since actors best action is voting infinite in some situations. This happens because moral values or slashing/punishment options are not integrated in the model
    • The distribution of V2.1,2 depends entirely on assumptions 1,2. Following these assumptions, the bigger the difference in strengths of the weight classes, the less likely I1 will occur, but the more likely I2 will. The bigger the size of the weight classes themselves, the bigger the chance I1 will occur, the less I2 will.
      • V2.1,2 could cancel eachother out to achieve I3.
    • V3 will increase the chance of I1.

References and previous work

Budget and Timeline

During September we’ve had only time to consider this and plant a stake in the ground. Our requested reward for September is as follows

Estimated Budget of Task: $[2000 September]
1000 Caspar and 1000 Allan, ~20 hours each
Estimated Timeline Required to Complete the Task: [Sep 30]
How will we measure completion? [Issue posted and comments addressed]

Caspar and Allan certify that if the issue concept is approved to go forward we will continue to work on this issue and bring it to completion (including submit one or more papers for publication)

Legal

Task Submitter shall not submit Tasks that will involve RHOC being transacted in any manner that (i) jeopardizes RHOC’s status as a software access token or other relevant and applicable description of the RHOC as an “asset”—not a security— or (2) violates, in any manner, applicable U.S. Securities laws.

@allancto
Copy link
Author

Sponsorship: I'd look to @timotheus, @phil, @theophoric, @luigidemeo, @ysgjay, @dckc , @JosDenmark , @pekkok, @vlad, @kent, @traviagio for support on this issue. Budgetary voting and blockchain Consensus are to my way of thinking related. In particular Vlad has argued that coalition forming should be assumed not avoided: built right into to our systems and our mathematical analysis as ground level hypotheses.

@dckc
Copy link
Contributor

dckc commented Sep 27, 2018

Game theory and economics is of course important work, but I'm struggling to see the direction here.

I don't see any acknowledgement here of the existing literature on the trust metric in use in the RChain bounty ssytem. I didn't design the trust metric. It was designed by Raph Levin in the early 2000s:

Theorem: The number of bad serves chosen is bounded by P x∈C(cx − 1), where C is the set of confused nodes -- Jesse Ruderman (2004). A comparison of two trust metrics.

The "Economic Game Theory of Weighted Voting Systems" title is awfully broad; is the scope of the proposed task actually that wide? If not, please refine the title.

The benefit to RChain is also vague: "Sponsored research in this area helps us understand, design and implement attack resistant systems." Any sponsored research?

"Issue posted and comments addressed" is an odd measure of completion for research. You're not suggesting this github issue as a venue for peer review of game theory research, are you? Oh... dGov18 ... isn't acceptance there a more relevant measure of completion?

@allancto
Copy link
Author

@dckc yes, as part of properly writing up this issue I'm committed to acknowledging Trustmetric and providing proper links and references. Also yes, the title is unnecessarily broad. I had thought about making it narrower but decided to leave it for now, hoping to attract more contributors. We'll need to refine the title and the issue statement itself if we continue into next month. Also, I've edited the "benefit" to "may help us to understand".

The issue work described here is only work we did in August and September, far from the "finish line" of analysis we can submit for publication. I'm asking for votes and support to reward work already done, in the suggested amount $2000. If that preliminary amount is voted for the preliminary work we've done, we're committed to continuing. If no rewards are voted for work already done we will take that as a clear signal and likely decide to not proceed with future work as proposed. You're correct, dGov18 submission is proposed as a measure of completion of "actual" analysis as opposed to the preliminary analysis we've done here. I am also careful to suggest "submission" rather than acceptance as the measure of completion so that it's clear our commitment will be to submit and we will not guarantee acceptance.

Thanks! -@allancto and @casparlusink

@dckc
Copy link
Contributor

dckc commented Sep 27, 2018

Hmm... I wonder if a smallish "present in abstract form" Zoom session is in order.

@ysgjay, others, are you game?

@dckc
Copy link
Contributor

dckc commented Sep 27, 2018

Does this work shed any light on #785 ?

@dckc
Copy link
Contributor

dckc commented Oct 8, 2018

With considerable hesitation, I backed the $2000 proposed budget with my vote. I don't know if this work is on track, and I'm not sure where sponsorship should come from, but I'd like to see more discussion of economics and game theory around the coop. We'll see whether others concur.

I suppose getting in touch with the RChain research group is in order. Assigning myself to do that...

@pmoorman
Copy link

pmoorman commented Oct 9, 2018

I wasn't sure how to go about tasks like these after the reset, but if @dckc thinks it can be supported, then I'd be glad to support it, too (after all I encouraged @casparlusink to take on this work in the first place).

Regarding sponsorship source
I'm wondering: the bounty system was initially funded as a project of it's own (right?). To what extend would a (modest) label be in place for operations/improvements of the bounty system? Pieces of work like these, as well as for instance maintenance work on the rewards.rchain.coop app could be funded through it.

Another suggestion could be to suggest a label like game theory or research or something similar, to do research on the areas where that's needed most (not only the bounty system, but also maybe vector attacks, supportive work on Casper POS, etc.). I'm wondering if people like Vlad and Philip (@phil on Discord) could be a lead/sponsor on that.

Are those ideas worth discussing?

@kitblake
Copy link
Contributor

kitblake commented Oct 9, 2018

Following @pmoorman and @dckc's lead, I voted a like budget, and the issue is provisioned.

@ravachol70
Copy link

ravachol70 commented Nov 21, 2018

Please add #liveness to the #game-theory and #research bag.

@allancto
Copy link
Author

allancto commented Nov 22, 2018 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants