Aragon Conviction Voting Model - Version 2¶

New to this model are the following elements:

• Influence - Participant social network where participants influence each others perception of a a proposal.
• Conflict - A network with the notion of supporting one proposal may mean going against an alternative proposal. For proposals with conflicts, an edge is created between them with a function to calculate the degree of conflict.
• Sentiment - Participant sentiment
• Updated trigger function to better represent 1Hive's implementation
• Updated plotting
• Updated affinity distribution to between -1, 1

An Introduction to Conviction Voting¶

Conviction Voting is an approach to organizing a communities preferences into discrete decisions in the management of that communities resources. Strictly speaking conviction voting is less like voting and more like signal processing. Framing the approach and the initial algorithm design was done by Michael Zargham and published in a short research proposal Social Sensor Fusion. This work is based on a dynamic resource allocation algorithm presented in Zargham's PhD Thesis.

The work proceeded in collaboration with the Commons Stack, including expanding on the pythin implementation to makeup part of the Commons Simulator game. An implemention of Conviction Voting as a smart contract within the Aragon Framework was developed by 1hive.org and is currently being used for community decision making around allocations their community currency, Honey.

The Word Problem¶

Suppose a group of people want to coordinate to make a collective decision. Social dynamics such as discussions, signaling, and even changing ones mind based on feedback from others input play an important role in these processes. While the actual decision making process involves a lot of informal processes, in order to be fair the ultimate decision making process still requires a set of formal rules that the community collecively agrees to, which serves to functionally channel a plurality of preferences into a discrete outcomes. In our case we are interested in a procedure which supports asynchronous interactions, an provides visibility into likely outcomes prior to their resolution to serve as a driver of good faith, debate and healthy forms of coalition building. Furthermore, participations should be able to show support for multiple initiatives, and to vary the level of support shown. Participants a quantity of signaling power which may be fixed or variable, homogenous or heterogenous. For the purpose of this document, we'll focus on the case where the discrete decisions to be made are decisions to allocate funds from a shared funding pool towards projects of interest to the community.

Converting to a Math Problem¶

Let's start taking these words and constructing a mathematical representation that supports a design that meets the description above. To start we need to define participants.

Participants¶

Let $\mathcal{A}$ be the set of participants. Consider a participant $a\in \mathcal{A}$. Any participant $a$ has some capacity to participate in the voting process $h[a]$. In a fixed quantity, homogenous system $h[a] = h$ for all $a\in \mathcal{A}$ where $h$ is a constant. The access control process managing how one becomes a participant determines the total supply of "votes" $S = \sum_{a\in \mathcal{A}} = n\cdot h$ where the number of participants is $n = |\mathcal{A}|$. In a smart contract setting, the set $\mathcal{A}$ is a set of addresses, and $h[a]$ is a quantity of tokens held by each address $a\in \mathcal{A}$.

Proposals & Shares Resources¶

Next, we introduce the idea of proposals. Consider a proposal $i\in \mathcal{C}$. Any proposal $i$ is associated with a request for resources $r[i]$. Those requested resources would be allocated from a constrained pool of communal resources currently totaling $R$. The pool of resources may become depleted because when a proposal $i$ passes $R^+= R-r[i]$. Therefore it makes sense for us to consider what fraction of the shared resources are being request $\mu_i = \frac{r[i]}{R}$, which means that thre resource depletion from passing proposals can be bounded by requiring $\mu_i < \mu$ where $\mu$ is a constant representing the maximum fraction of the shared resources which can be dispersed by any one proposal. In order for the system to be sustainable a source of new resources is required. In the case where $R$ is funding, new funding can come from revenues, donations, or in some DAO use cases minting tokens.

Participants Preferences for Proposals¶

Most of the interesting information in this system is distributed amongst the participants and it manifests as preferences over the proposals. This can be thought of as a matrix $W\in \mathbb{R}^{n \times m}$.

These private hidden signals drive discussions and voting actions. Each participant individually decides how to allocate their votes across the available proposals. Participant $a$ supports proposal $i$ by setting $x[a,i]>0$ but they are limited by their capacity $\sum_{k\in \mathcal{C}} x[a,k] \le h[a]$. Assuming each participant chooses a subset of the proposals to support, a support graph is formed.

Aggregating Information¶

In order to break out of the synchronous voting model, a dynamical systems model of this system is introduced.

Participants Allocate Voting Power¶

System Accounts Proposal Conviction¶

Understanding Alpha¶

• https://www.desmos.com/calculator/x9uc6w72lm
• https://www.desmos.com/calculator/0lmtia9jql

Converting Signals to Discrete Decisions¶

Conviction as kinetic energy and Trigger function as required activation energy.

The Trigger Function¶

https://www.desmos.com/calculator/yxklrjs5m3

Below we show a sweep of the trigger function threshold:

Resolving Passed Proposals¶

Social Systems Modeling¶

Subjective, exploratory modeling of the social system interacting through the conviction voting algorithm.

Sentiment¶

Global Sentiment -- the outside world appreciating the output of the community Local Sentiment -- agents within the system feeling good about the community

Social Networks¶

Preferences as mixing process (social influence)

Relationships between Proposals¶

Some proposals are synergistic (passing one makes the other more desireable) Some proposals are (parially) substitutable (passing one makes the other less desirable)

cadCAD Overview¶

In the cadCAD simulation methodology, we operate on four layers: Policies, Mechanisms, States, and Metrics. Information flows do not have explicit feedback loop unless noted. Policies determine the inputs into the system dynamics, and can come from user input, observations from the exogenous environment, or algorithms. Mechanisms are functions that take the policy decisions and update the States to reflect the policy level changes. States are variables that represent the system quantities at the given point in time, and Metrics are computed from state variables to assess the health of the system. Metrics can often be thought of as KPIs, or Key Performance Indicators.

At a more granular level, to setup a model, there are system conventions and configurations that must be followed.

The way to think of cadCAD modeling is analogous to machine learning pipelines which normally consist of multiple steps when training and running a deployed model. There is preprocessing, which includes segregating features between continuous and categorical, transforming or imputing data, and then instantiating, training, and running a machine learning model with specified hyperparameters. cadCAD modeling can be thought of in the same way as states, roughly translating into features, are fed into pipelines that have built-in logic to direct traffic between different mechanisms, such as scaling and imputation. Accuracy scores, ROC, etc. are analogous to the metrics that can be configured on a cadCAD model, specifying how well a given model is doing in meeting its objectives. The parameter sweeping capability of cadCAD can be thought of as a grid search, or way to find the optimal hyperparameters for a system by running through alternative scenarios. A/B style testing that cadCAD enables is used in the same way machine learning models are A/B tested, except out of the box, in providing a side by side comparison of muliple different models to compare and contrast performance. Utilizing the field of Systems Identification, dynamical systems models can be used to "online learn" by providing a feedback loop to generative system mechanisms.

Differential Specification¶

Schema of the states¶

The model consists of a temporal in memory graph database called network containing nodes of type Participant and type Proposal. Participants will have holdings and sentiment and Proposals will have funds_required, status(candidate or active), conviction Tthe model as three kinds of edges:

• (Participant, participant), we labeled this edge type "influencer" and it contains information about how the preferences and sentiment of one participant influence another
• (Proposal, Proposal), we labeled this edge type "conflict" and it contains information about how synergistic or anti-synergistic two proposals are; basically people are likely to support multiple things that have synergy (meaning once one is passed there is more utility from the other) but they are not likely to pass things that have antisynergy (meaning once one is passed there is less utility from the other).
• The edges between Participant and Proposal, which are described below.

Edges in the network go from nodes of type Participant to nodes of type Proposal with the edges having the key type, of which all will be set to support. Edges from participant $i$ to proposal $j$ will have the following additional characteristics:

• Each pairing (i,j) will have affinity, which determines how much $i$ likes or dislikes proposal $j$.
• Each participant $i$, assigns its $tokens$ over the edges (i,j) for all $j$ such that the summation of all $j$ such that Sum_j = network.edges[(i,j)]['tokens'] = network.nodes[i]['holdings']. This value of tokens for participants on proposals must be less than or equal to the total number of tokens held by the participant.
• Each pairing (i,j) will have conviction local to that edge whose update at each timestep is computed using the value of tokens at that edge.
• Each proposal j will have a conviction which is equal to the sum of the conviction on its inbound edges: network.nodes[j]['conviction'] = Sum_i network.edges[(i,j)]['conviction'].

The other state variable in the model is funds, which is a numpy floating point.

The system consists of 100 time steps without a parameter sweep or monte carlo.

Partial State Update Blocks¶

Each partial state update block is kind of a like a phase in a phased based board game. Everyone decides what to do and it reconciles all decisions. One timestep is a full turn, with each block being a phase of a timestep or turn. We will walk through the individaul Partial State update blocks one by one below.

{
# system.py: 
'policies': { 
    'random': driving_process
},
'variables': {
    'network': update_network,
    'funds':increment_funds,
}

To simulate the arrival of participants and proposal into the system, we have a driving process to represent the arrival of individual agents. We use a random uniform distribution generator, over [0, 1), to calculate the number of new participants. We then use an exponential distribution to calculate the particpant's tokens by using a loc of 0.0 and a scale of expected holdings, which is calculated by .1*supply/number of existing participants. We calculate the number of new proposals by

proposal_rate = 1/median_affinity * (1+total_funds_requested/funds)
rv2 = np.random.rand()
new_proposal = bool(rv2<1/proposal_rate)

The network state variable is updated to include the new participants and proposals, while the funds state variable is updated for the increase in system funds. To see the partial state update code, click here

{
  # participants.py   
  'policies': {
      'completion': check_progress 
    },
    'variables': { 
        'sentiment': update_sentiment_on_completion, #not completing projects decays sentiment, completing bumps it
        'network': complete_proposal
    }
},

In the next phase of the turn, to see the logic code, click here, the check_progress behavior checks for the completion of previously funded proposals. The code calculates the completion and failure rates as follows:

likelihood = 1.0/(base_completion_rate+np.log(grant_size))

failure_rate = 1.0/(base_failure_rate+np.log(grant_size))
if np.random.rand() < likelihood:
    completed.append(j)
elif np.random.rand() < failure_rate:
    failed.append(j)

With the base_completion_rate being 100 and the base_failure_rate as 200.

The mechanism then updates the respective network nodes and updates the sentiment variable on proposal completion.

  # proposals.py
  'policies': {
      'release': trigger_function 
    },
    'variables': { 
        'funds': decrement_funds, 
        'sentiment': update_sentiment_on_release, #releasing funds can bump sentiment
        'network': update_proposals 
    }
},

The trigger release function checks to see if each proposal passes or not. If a proposal passes, funds are decremented by the amount of the proposal, while the proposal's status is changed in the network object.

{ 
    # participants.py
    'policies': { 
        'participants_act': participants_decisions
    },
    'variables': {
        'network': update_tokens 
    }
}

The Participants decide based on their affinity if which proposals they would like to support,to see the logic code, click here. Proposals that participants have high affinity for receive more support and pledged tokens than proposals with lower affinity and sentiment. We then update everyone's holdings and their conviction for each proposal.

Model next steps¶

The the model described above is the second iteration model that covers the core mechanisms of the Aragon Conviction Voting model. Below are next additional dynamics we can attend to enrich the model, and provide workstreams for subsequent iterations of this lab notebook.

• Mixing of token holdings among participants
• Departure of participants
• Proposals which are good or no good together
• Affects of outcomes on sentiment

Simulation¶

Configuration¶

Let's factor out into its own notebook where we review the config object and its partial state update blocks.

Initialization¶

To create the genesis_states, we create our in-memory graph database within networkx.

Hyperparameters¶

• $\beta$ = .2 # maximum share of funds a proposal can take
• $\rho$ = 0.002 # tuning param for the trigger function
• $\alpha$ = 1/8 = 1/2^3 = 3 day half-life when timestep is 1 day
• supply = 21706 # Honey supply balance as of 7-17-2020
• initial_sentiment = .9
• n= 24 #initial participants
• m= 3 #initial proposals
• sensitivity = .75
• tmin = 7 #unit days; minimum periods passed before a proposal can pass
• min_supp = 50 #number of tokens that must be stake for a proposal to be a candidate
• base_completion_rate = 100
• base_failure_rate = 200
• initial_funds = 48000 # in xDai

Exploring the State Data Structure¶

A graph is a type of temporal data structure that evolves over time. A graph $\mathcal{G}(\mathcal{V},\mathcal{E})$ consists of vertices or nodes, $\mathcal{V} = \{1...\mathcal{V}\}$ and is connected by edges $\mathcal{E} \subseteq \mathcal{V} \times \mathcal{V}$.

See Schema of the states above for more details

Let's explore!

Proposals initially start without any conviction, and with the status of a candidate. If the proposal's amount of conviction is greater than it's trigger, then the proposal moves to active and it's funds requested are granted.

All initial proposal start with 0 conviction and state 'candidate'we can simply examine the amounts of funds requested

Conviction is a concept that arises in the edges between participants and proposals in the initial conditions there are no votes yet so we can look at that later however, the voting choices are driven by underlying affinities which we can see now.

Run simulation¶

Now we will create the final system configuration, append the genesis states we created, and run our simulation.

After the simulation has run successfully, we perform some postprocessing to extract node and edge values from the network object and add as columns to the pandas dataframe. For the rdf, we take only the values at the last substep of each timestep in the simulation.

Conclusion¶

We have created a simplified conviction voting model that illustrates the state objects, and provides descriptions of how the model fits together. In subsequent notebooks, we will expand the model to introduce additional complexity to more fit real world implementations.