merging jeff changes

README.md

@@ -7,7 +7,7 @@ This cadCAD model and notebook series is a collaboration between [Aragon Project
 ## Table of Contents
 
 ### 1. Supporting documentation for context
-* [Readme doc]() (you are here): For a high level exploration of CV and relevant topics, start here
+* [Readme doc]() (you are here): For a high level exploration of Conviction Voting and what exactly we're trying to do with this model, start right here.
 * [Conviction Voting Algorithm Overview](https://github.com/BlockScience/Aragon_Conviction_Voting/blob/master/algorithm_overview.md): For a deeper understanding of the CV algorithm, including it's mathematical derivation, read this document
 * [Deriving the Alpha Parameter](https://nbviewer.jupyter.org/github/BlockScience/Aragon_Conviction_Voting/blob/master/models/v3/Deriving_Alpha.ipynb): For an in-depth look at the specific considerations around the alpha parameter, which sets the half life decay of conviction, read this notebook
 * [Explaining the Trigger Function](https://nbviewer.jupyter.org/github/BlockScience/Aragon_Conviction_Voting/blob/master/models/v3/Trigger_Function_Explanation.ipynb): For an in-depth look at the trigger function equation and how proposals pass from candidate to active status, read this notebook
@@ -24,22 +24,20 @@ This cadCAD model and notebook series is a collaboration between [Aragon Project
 ___
 <br>
  
-# Current CV Deployments
 
-## 1Hive
-The [1Hive](https://www.1hive.org) community has been actively developing Conviction Voting contracts in collaboration with BlockScience and the Commons Stack since early 2019. They currently have a DAO live on the xDAI network at [1hive.org](https://www.1hive.org) that uses a native governance token (Honey) to allocate funds to proposals via Conviction Voting.
+# Background information & concepts addressed
 
-To see Conviction Voting deployed in smart contracts with a basic user interface, check out the [1Hive Github](https://github.com/1Hive/conviction-voting-app).
+## What is this cadCAD model trying to do?
+In cyber-physical systems like international power grids, global flight networks, or socioeconomic community ecosystems, engineers model simulated replicas of their system, called digital twins. These models help to manage the complexity of systems that have trillions of data points and are constantly in flux. These simulations channel the information into pathways that allow humans to understand what is going on in their ecosystem at a high level, so they can intervene where and as appropriate. (Like hitting a breaker switch when a fault is cleared in a power system).
 
-## Commons Simulator
+![img](https://i.imgur.com/kb4Tnh6.jpg)
 
-The [Commons Stack](https://www.commonsstack.org) has been working on a 'Commons Simulator' to facilitate user understanding of these novel governance tools. Progress on Conviction Voting can be viewed in [the Commons Stack Github repo](https://github.com/commons-stack/coodcad/tree/bigrewrite).
+Digital twins can be considered like a flight simulator, which can be used to run your system through a billion different "tests", varying one parameter at a time, to see what effects may throw your system out of balance. As engineers with public safety in mind, we must understand the tipping points of our systems, and ensure mechanisms are in place to push the system back towards balance if and when they enter their boundary conditions of safety.
 
-<br>
+This cadCAD model is a digital twin of Conviction Voting, as applied in the 1Hive DAO ecosystem. It can be used to provide operational support in decision making both during the design stage, and also in the continuous governance of the 1Hive system, providing [Computer Aided Governance](https://medium.com/block-science/computer-aided-governance-cag-a-revolution-in-automated-decision-support-systems-9faa009e57a2) for 1Hive members. 
 
-___
+The notebooks contained here are a mix of code snippets, explainer content, simulations, and a whole lot of background to get you more familiar with CV as a concept, and perhaps even diving into modelling similar systems, or extending this model even further using cadCAD. If you have any questions about this model or how to build with it in cadCAD, feel free to email jeff@block.science.
 
-## Background information & concepts addressed
 <br>
 
 ## Conviction Voting Basics
@@ -59,11 +57,42 @@ As our governance toolkits continue to expand with novel tools like Conviction V
 
 Conviction Voting offers us new insight into the collective intent of our communities. It offers us a richer signal of the emergent and dynamic preferences of a group, such that we can better understand and discuss important issues as communities. It eliminates attack vectors of ad hoc voting such as last minute vote swings, and reduces user friction by not requiring set times to cast a vote.  
 
+## Different Flavors of Conviction Voting
+
+The design space for this new governance tool is wide and unexplored. From its academic origins in Dr. Zargham's PhD research in multi agent coordination systems, Conviction Voting was called [Social Sensor Fusion](https://github.com/BlockScience/conviction/blob/master/social-sensorfusion.pdf) and was a continuous 'fusion' of individual desires into a collective sentiment signal. This suggests there could be multiple "flavors" of Conviction Voting:
+
+* **Discrete proposal CV**: Like the 1Hive or Commons Stack model, this version of CV fuses continuous preferences into a conviction signal, passing the proposal at a specific point in time, when sufficient community support has been reached. 
+
+![img](https://i.imgur.com/cx5pCxH.png)
+
+* **Continuous parameter CV:** A community may wish to have certain aspects of their socioeconomic system to be continuously decided by collective sentiment. Perhaps the rate of a community token entry/exit (Tobin) tax, or the rate of community UBI. 
+
+![img](https://i.imgur.com/5hDgMTk.png)
+
+There are likely to be many more useful applications of this real-time governance tool in community decision making and beyond. We look forward to continuing this research and creating the open source foundations of models which can be iterated towards widely varying scenarios for creating high leverage impact.
+
 ## Conviction Voting In-Depth
 Conviction voting is based on a linear system akin to a capacitor which "charges up" dynamically and proposals pass when a certain level of collective energy is reached. The details are explained and demonstrated throughout this repo but the best place to start is the [Conviction Voting Algorithm Overview](algorithm_overview.md). For more details on the charging up mechanics and the parameter $\alpha$ see the [Deriving Alpha Parameter Explainer](https://nbviewer.jupyter.org/github/BlockScience/Aragon_Conviction_Voting/blob/master/models/v3/Deriving_Alpha.ipynb) notebook and for more details on the proposal passing mechanism,  see the [Trigger Function Explainer](https://nbviewer.jupyter.org/github/BlockScience/Aragon_Conviction_Voting/blob/master/models/v3/Trigger_Function_Explanation.ipynb) notebook.
 
 <br>
 
+___
+
+# Current CV Experiments
+
+## 1Hive
+The [1Hive](https://www.1hive.org) community has been actively developing Conviction Voting contracts in collaboration with BlockScience and the Commons Stack since early 2019. They currently have a DAO live on the xDAI network at [1hive.org](https://www.1hive.org) that uses a native governance token (Honey) to allocate funds to proposals via Conviction Voting.
+
+To see Conviction Voting deployed in smart contracts with a basic user interface, check out the [1Hive Github](https://github.com/1Hive/conviction-voting-app).
+
+## Commons Simulator
+
+The [Commons Stack](https://www.commonsstack.org) has been working on a 'Commons Simulator' to facilitate user understanding of these novel governance tools. Progress on Conviction Voting can be viewed in [the Commons Stack Github repo](https://github.com/commons-stack/coodcad/tree/bigrewrite).
+
+<br>
+
+___
+
 ## What is cadCAD?
 cadCAD (complex adaptive dynamics Computer-Aided Design) is a python based modeling framework for research, validation, and Computer Aided Design of complex systems. Given a model of a complex system, cadCAD can simulate the impact that a set of actions might have on it. This helps users make informed, rigorously tested decisions on how best to modify or interact with the system in order to achieve their goals. cadCAD supports different system modeling approaches and can be easily integrated with common empirical data science workflows. Monte Carlo methods, A/B testing and parameter sweeping features are natively supported and optimized for.
 
@@ -80,8 +109,12 @@ pip install cadCAD==0.4.18
 
 Then run cd Aragon_Conviction_Voting to enter the repository. Finally, run jupyter notebook to open a notebook server to run the various notebooks in this repository.
 
+Check out the [cadCAD forum](https://community.cadcad.org/t/python-newbies-setup-for-cadcad/101) for more information about installing and using cadCAD.
+
 <br>
 
+___
+
 ## Further Background Reading
 
 ### Systems Thinking

algorithm_overview.md

@@ -1,85 +1,112 @@
-# An Introduction to Conviction Voting
+# Mathematically Formalizing to the Conviction Voting Algorithm
 
-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](https://github.com/BlockScience/conviction/blob/master/social-sensorfusion.pdf). This work is based on a dynamic resource allocation algorithm presented in Zargham's PhD Thesis.
+## Background
+---
+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](https://github.com/BlockScience/conviction/blob/master/social-sensorfusion.pdf). This work is based on a dynamic resource allocation algorithm presented in Dr. Zargham's PhD Thesis.
 
 The work proceeded in collaboration with the Commons Stack, including expanding on the python 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](https://1hive.org/) and is currently being used for community decision making around allocations their community currency, Honey.
 
-## The Word Problem
+## Defining 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
+### Defining the 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
+### Defining Proposals & Shared 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
+### Defining 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}$.
-![Replace this later](https://i.imgur.com/vxKNtxi.png)
+![image of participant/proposal affinity matrix](https://i.imgur.com/vERr8Zv.png)
 
 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.
 ![pic](https://i.imgur.com/KRh8tKn.png)
 
 ## Aggregating Information
 
-In order to break out of the synchronous voting model, a dynamical systems model of this system is introduced.
+___
+
+In order to break out of the synchronous ad-hoc voting model, a dynamical systems model of this system is introduced that fuses collective community preferences into a single signal. The mathematical derivation of this process can be found below.
 
 ### Participants Allocate Voting Power
 
-![pic](https://i.imgur.com/DZRDwk6.png)
+___
 
-### System Accounts Proposal Conviction
+![pic](https://i.imgur.com/DZRDwk6.png)
+In the above diagram, we examine the participant view. Participant $a$ with holdings $h$ at time $t$ supports proposals $i$ and $j$ with $x$ conviction. The sum of all conviction asserted by participant $a$ is between 0 and the total holdings of participant $a$.
+
+### System Accounting of Proposal Conviction
+
+___
 
 ![pic](https://i.imgur.com/euAei5R.png)
 
-### Understanding Alpha
+In the above diagram, we examine the proposal view. Proposal $j$ with total conviction $y$ at time $t$ is supported by participants $a$, $b$ and $c$ with $x$ conviction. The total conviction $y$ at time $t+1$ is equal to the total conviction at time $t$ decremented by an exponential decay $\\alpha$ plus the sum of all conviction from $k$ agents in time step $t$.
 
-<https://www.desmos.com/calculator/x9uc6w72lm>
-<https://www.desmos.com/calculator/0lmtia9jql>
+### Understanding the Alpha Parameter
+___
+For a deeper exploration of the $alpha$ parameter, please read more in the [Deriving Alpha notebook](https://nbviewer.jupyter.org/github/BlockScience/Aragon_Conviction_Voting/blob/master/models/v3/Deriving_Alpha.ipynb)
 
-<https://p2pmodels.github.io/cs-sim/>
 
 ## Converting Signals to Discrete Decisions
+___
 
-Conviction as kinetic energy and Trigger function as required activation energy.
+Conviction can be considered like a fluctuating kinetic energy, with the Trigger function acting as a required activation energy for proposals to pass. This is the mechanism by which a continuous community preference turns into a discrete action event: passing a proposal. See the [Trigger Function Explanation notebook](https://nbviewer.jupyter.org/github/BlockScience/Aragon_Conviction_Voting/blob/master/models/v3/Trigger_Function_Explanation.ipynb) for more details around the trigger function and how it works.
 
 ### The Trigger Function
+___
+For a deeper exploration of the trigger function, please read more in the [Trigger Function Explainer notebook](https://nbviewer.jupyter.org/github/BlockScience/Aragon_Conviction_Voting/blob/master/models/v3/Trigger_Function_Explanation.ipynb)
 
-<https://www.desmos.com/calculator/yxklrjs5m3>
 
 ### Resolving Passed Proposals
+___
 
 ![pic](https://i.imgur.com/lmOl9HE.png)
 
 ## Social Systems Modeling
+___
 
-Subjective, exploratory modeling of the social system interacting through the conviction voting algorithm.
+In the conviction voting model, multiple graph structures are used to represent participants and proposals to represent a subjective, exploratory modeling of the social system interacting.
 
-### Sentiment
+### Sentiment:
 
-Global Sentiment -- the outside world appreciating the output of the community
-Local Sentiment -- agents within the system feeling good about the community
+* Global Sentiment denotes the outside world appreciating the output of the community. 
+* Local Sentiment denotes the agents within the system feeling good about output of the community. 
+* Sentiment increases when proposals pass and work is completed in the community, and decreases when proposals fail and community progress stalls.
 
-### Social Networks
+### Relationships between Participants:
 
-Preferences as mixing process (social influence)
+* Edges from participant to participant denote influence (to represent subjective social influence) and are assigned randomly via mixing processes.
+
+![Participant Influence Graph](https://i.imgur.com/zQziRA7.png)
 
 ### 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)
+* Edges from proposal to proposal represent conflict, which can be positive or negative. 
+* Some proposals are synergistic (passing one makes the other more desirable). 
+* Some proposals are (partially) substitutable (passing one makes the other less desirable).
+
+![Proposal Conflict Graph](https://i.imgur.com/CNjLhmr.png)
 
 ## Glossary of Notation
-
-### Summary State Variables
+___
+### Summary of State Variables
 
  Notation | Definition|
 |--- | --- |
@@ -88,62 +115,74 @@ Some proposals are (parially) substitutable (passing one makes the other less de
 |$n_t$ | |
 |$m_t$ | |
 |$W_t$ | |
-|$X_t$ | |
-|$y_t$ | |
+|$X_t$ | Individual participant conviction at time t|
+|$y_t$ | Total aggregated community conviction at time t|
 |$y^*_t$ | |
-|$R_t$ | |
-|$S_t$ | |
+|$R_t$ | Available resources in the communal funding pool|
+|$S_t$ | Effective supply of tokens available for community governance|
 
-### Summary Laws of Motion
+<br> 
+<br>
 
-A new address $a$ joins the community of participants:
+## Summary Laws of Motion / State Transition
+
+* A new address $a$ joins the community of participants:
 $\mathcal{A}_{t+1} = \mathcal{A}_t \cup \{a\}$
 $h_{t+1}[a]= \Delta h >0$
 
-An address $a$ leaves the community of participants:
+* An address $a$ leaves the community of participants:
 $\mathcal{A}_{t+1} = \mathcal{A}_t \backslash \{a\}$
 $h_{t+1}[a]= 0$
 
-A proposal $i$ is added to the set of candidates
+* A proposal $i$ is added to the set of candidates
 $\mathcal{C}_{t+1} = \mathcal{C}_t \cup \{i\}$
 
-A proposal $i$ is removed from the set of candidates
+* A proposal $i$ is removed from the set of candidates
 $\mathcal{C}_{t+1} = \mathcal{C}_t \backslash\{i\}$
 
-Resources are added to the shared resource pool
+* Resources are added to the shared resource pool
 $R_{t+1}= R_t+ \Delta r$
 
-Update Conviction Required to pass proposals
+* Update Conviction Required to pass proposals
 $y^*_{t+1} = [\cdots ,f(\mu_i), \cdots]$
 where $\mu_i = \frac{r[i]}{R_t}$
 
-A participant allocates their support
+* A participant allocates their support
 $X_{t+1}[a,: ] = [\cdots,x[a,i],\cdots]$
 s.t. $\sum_{i\in \mathcal{C}_t}x[a,i]\le h[a]$
 
-A proposal is passed given $y_t[i] \ge y^*_t[i]$
+* A proposal is passed given $y_t[i] \ge y^*_t[i]$
 $\mathcal{C}_{t+1} = \mathcal{C}_t \backslash\{i\}$
 $R_{t+1}= R_t- r[i]$
 
-Update Conviction
+* Update Conviction
 $y_{t+1}[i] =\alpha\cdot y_t[i] + \sum_{a\in \mathcal{A}_t} x[a, i]$
 
-### Parameters
+<br> 
+
+## Parameters
 
  Notation | Definition|
 |--- | --- |
 |$\alpha$ | The decay rate for previously accumulated conviction |
 |$\beta$ | Upper bound on share of funds dispersed in the example Trigger Function|
-|$f(z)$| Trigger function determines when a proposal has sufficient conviction to pass|
+|$f(z)$| Trigger function that determines when a proposal has sufficient conviction to pass|
 |$\rho$ | Scale Parameter for the example Trigger Function  |
 
 Recall that the Trigger Function, $f(z)$ satisfies $f:[0,1]\rightarrow \mathbb{R}_+$
 e.g. $f(z) = \frac{\rho S }{(1-\alpha)(z-\beta)^2}$
 
-### Additional Considerations
+<br>
 
-timescales
-minimum candidacy times
-minimum conviction required for small proposals
-effective supply
-proposal statuses
+## Additional Considerations when Deploying CV
+
+* Timescales
+    * whether your system is operating in block times, or more human understandable timescales like hours, days or weeks, these considerations need to be factored into your model
+* Minimum candidacy times
+    * proposals should be active for a minimum period to ensure appropriate dialog occurs within the community, regardless of level of support
+* Minimum conviction required for small proposals
+    * to prevent small proposal spamming from draining the communal funding pool, all proposals should have some minimum conviction required to pass
+* Effective supply
+    * to avoid slow conviction aggregation due to "inactive" tokens (e.g. locked up in cold storage or liquidity pool, without active participation in governance), effective supply is the portion of tokens that are active in community governance
+* Proposal statuses
+    * proposals can exist in multiple status types, which can be expanded as this model grows