---
tags: RFC, dapp
---
TzVote
===

# Glossary
- **Delegate** = Baker
- **Delegator** = Tz owner not holding roll, but >1 Tz delegated
- **Staker** = Delegator or Delegate , i.e people who own Tz

# Initial requirements

1. Generic voting app on Tezos. Example : Due to technical bottlenecks, not all Stakers can participate to Tezos votes, and so Delegation mecanism has been set in place to resolve it. Thus one representative members, named Bakers, can participate. The counterparty is that trust can be lost between Tz owners and Bakers. Either Bakers do not know what their delegators want, either delegators do not trust delegates to vote on same alignment. One solution would be Tz owners to be able to vote during Proposal&Exploratory phases. These votes do not count on the real phase process on Tezos like Bakers do, but bring enough trust so Bakers can take it into account. On the other way, We could be able to compare Bakers end vote its Tz owners' vote aggregated result.
2. Core development founding is trusted/accepted and done today by Tezos Foundation. To move power from TF to the community, a tool is needed to do "inflation founding". Democratic voting is the tool that can enable it.
3. Voting mechanism is too much focused on Tezos intrinsic money/economics purposes. We would like to open questions to a wider scope that could be social or political oriented
4. Marigold is considered as "underdog" company. Bring new Marigold tool for more visibility
5. Application has to be fast, very cheap cost for the voters, easily accessible, secure
5.1 : Bakers voting based on capital power
5.2 : Delegators voting based on existence power
>[Proof of existence](#Proof-of-Existence)
>[name=Benjamin Fuentes]
In order to have an existence power, we need to introduce a proof of existence

# Implicit requirements

6. **Avoid flooding**. In any case, block any person to create unlimited voting sessions or create unlimited accounts to have unlimited votes
7. **Verification proof&tooling**. Need to prove that vote belongs to a user + content integrity + need to prove that vote is recorded on immutable storage at a date to do the final count
8. **Anonymous voting** : Can create and verify anonymous voting sessions
9. Unitary test

# Answers (Answer --to--> RequirementList)

1. -> [1, 2, 3, 5.1] : Poll can be created by anyone. Session can be arbitrary duration or stick to a specific schedule (ex: Self Amendment process periods)

## Voting templates :

### 1.1 ***Tezos*** (i.e capital power :moneybag:)
**creation** => (*1* question, *n* options) , **vote** => *1* choice , **voting power** => rolls :moneybag:, **periodicity** => Tezos amendment period

### 1.2 ***Free Simple poll***
**creation** => (*1* question, *n* options) , **vote** => *1* choice , **voting power** => *1 identity = 1 vote* :raising_hand:

### 1.3 ***Permissioned Simple poll***
**creation** => (*1* question, *n* options) , **vote** => *1* choice , **voting power** => *permissioned address balance* :raising_hand::heavy_check_mark:

### 1.3.1 ***Permissioned OIDC Simple poll***
**creation** => (*1* question, *n* options) , **vote** => *1* choice , **voting power** => *permissioned address balance* :raising_hand::heavy_check_mark:

OIDC will serve as the voter list here, there is no admin entrypoints to add or remove voters

sequenceDiagram
  Note left of User: 
  User->>backend: Claim OIDC ownership. SignChallenge(tz1xxx) 
  backend->>User: redirect to OIDC provider login page
  User->>OIDC provider: Login(user+pwd)
  OIDC provider->>backend: callback(code)  
  backend-->OIDC provider: callback(code)  
  

### 1.4 ***BF (Borda-Fibonacci)***
https://en.wikipedia.org/wiki/Borda_count

**creation** => (*1* question, *n* options) , **vote** => *n* choices , **voting power** => **$BF^{identity}$** :raising_hand:

BF is defined as follow :
Instead of linear vote allocation (1,2,3,...) uses a Fibonacci suite (1,2,3,5,8,...) to enforce clear positions. To avoid exponential results on high option choice number, need to balance the points as for the sum of user's vote allocation should be zero : **$\forall$ j a voter $\cap$ $\forall$ i a vote choice, $\sum_{i=1}^{n}votes(i,j)$=0**. Ex : For a vote with 8 options, allocation of points is among list [5,-3,-2,-1,1,2,3,5] , with 9 options is [5,-3,-2,-1,0,1,2,3,5] , with 10 is [-8,5,-3,-2,-1,1,2,3,5,8] etc ..

### 1.5 **Samarkand**

**creation** => (*1* question, *n* options) , **vote** => *n* choices , **voting power** => rolls :moneybag:

The difference with Tezos implementation is that a voter stack *x* Tezos and has to distribute all Tezos amongs all options. Each allocation is bounded between [-x,x] and **$\forall$ j a voter $\cap$ $\forall$ i a vote choice, $\sum_{i=1}^{n}votes(i,j)$=0**.
Example for 6 voters A..F financial allocation:

|Option |A |B |C |D |E |F |Result |Rank|
|- |- | - | - | - | -| -| -| -|
|1 |100| 75 |−100|0 |−70|0 |5 | 2|
|2 |−50| 25 | 50|100 |−30|100 |195 | 3|
|3 |−50|−100| 50|−100|100|−100|−200 | 1|

For the winner **3** of this election, we can resolve the financial resolution as this :

|A |B |C |D |E |F |
|- | - | - | - | -| -|
|−50|−100| 50|−100|100|−100|

**$\sum gains$=150**
**$\sum loses$=-350**
**$\Delta$gains-loses=-200** $\leftarrow$ negative result ! Winners need to finance 200 to losers

Smooth resolution redistribution. Election voter losers take their gains, Election voter winners lose *reduces* money proportionally

|A |B |C |D |E |F |sum|
|- | - | - | - | -| -| -|
|−50/350*200|−100/350*200| 50|−100/350*200|100|−100/350*200|0|
|−28.57|−57.14| 50|−57.14|100|−57.14|0|

---
## **Summary**
| voting templates | creation (#question,#options)| vote (# choices) | voting power (function) | periodicity | no censorship | privacy |
| ---------------- | -------- | -------- | -------- |-------- | --- |--- |
| Tezos | 1 , n | 1 | :moneybag: | Tezos Amendment cycle | :heavy_check_mark: | :negative_squared_cross_mark: (actual version) |
| Free Simple Poll | 1 , n | 1 | :raising_hand:=>1 | FromDate , ToDate | :heavy_check_mark: | :negative_squared_cross_mark: (actual version) |
| Permissioned Simple Poll | 1 , n | 1 | :raising_hand::heavy_check_mark:=>1 | FromDate , ToDate | :negative_squared_cross_mark: (owner whitelist) | :negative_squared_cross_mark: (actual version) |
| Permissioned OIDC Simple Poll | 1 , n | 1 | :raising_hand::heavy_check_mark:=>1 | FromDate , ToDate | :negative_squared_cross_mark: (OIDC whitelist) | :negative_squared_cross_mark: (actual version) |
| BF | 1 , n | n | :raising_hand:=>voteAllocation | FromDate , ToDate |:heavy_check_mark: | :negative_squared_cross_mark: (actual version) |
| Samarkand | 1 , n | n | Samarkand(:moneybag:)=>voteAllocation | Tezos Amendment cycle |:heavy_check_mark: | :negative_squared_cross_mark: (actual version) |

---

2. -> [4] : Free web Dapp hosted by Marigold that communicates with user browser wallet. [not MVP]Later, a mobile solution could be a plus.
3. -> [5.1] Use Tezos on-chain smart contract at low cost.
4. -> [6, 5.1] To avoid flooding, bakers stack *x* Tezos
5. -> [7, 5.1] Using a smart contract can prove computation is effectively initiated from a proven signed transaction. We can start with vote in clear as first iteration
6. -> [8] [Not in MVP]For 5.2, need to provide a script to check vote result : block address, hash and timestamp valid proofs, using homomorphic computation on encrypted data ? Or giving unit tests doing the same.

# User stories
0. Everyone can login
1. Owner can create/edit/delete voting session
2. Everyone can search and vote during voting session
3. Everyone can view final results
4. A voter can be alerted in real time inside the browser of a final result for earlier sessions he voted on
5. Every Tezos public addresses are converted to xxx.tez if exists

# Architecture

## Basic (MVP)


## Oracle

Smart contract cannot get the current voting period index, to provide this data, we create an oracle. The oracle is another smartcontract providing this information on the chain. A schedule job push/refresh the current period every end at interval of **min block creation interval**

Flow between the smart contract and the oracle is as follow


## Schedule job

The role of the schedule job is to maintain the storage of oracle uptodate. Here below is the pseudo-code algorithm :

WAIT_TIME = 15s
TEZOS_RPC_URL =  https://hangzhounet.api.tez.ie
TEZOS_RPC_ADDRESS = "KT1GLuqbSEoaRb3GE4UtUgGkDukVS766V53A"
TEZOS_SECRET_KEY = "ecXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
TEZOS_NETWORK = "hangzhounet"

WHILE TRUE
    RESPONSE = CALL GET RPCNODEAPIURL+"/votes/current_period"
    PERIOD = RESPONSE.voting_period.index
    Tezos.setProvider({ signer: new InMemorySigner(TEZOS_SECRET_KEY) });
    CONTRACT = Tezos.wallet.at(TEZOS_RPC_ADDRESS);
    
    CURRENT_VALUE = CONTRACT.storage.get(TEZOS_NETWORK)
    
    IF(CURRENT_VALUE != PERIOD)
    THEN CONTRACT.methods.updateCurrentVotingPeriod (TEZOS_NETWORK,VALUE).send();
    
    WAIT(WAIT_TIME)

## Indexer

We will use the TZKT.IO indexer (https://github.com/baking-bad/tzkt)

## One or several smartcontrats for a voting session ?

| Criteria | 1 smart contract per session | all sessions in 1 smart contract |
| -------- | -------- | -------- |
|administration| user | marigold |
|isolation complexity / right delegation| :white_check_mark: single tenant| :white_check_mark: multi tenant user system with additional rights |
|ownership/no censorship| :white_check_mark: user | :negative_squared_cross_mark: marigold|
|origination cost| :negative_squared_cross_mark: cost at each deployment paid by user |:white_check_mark: 1 paid by marigold |
|fee income mecanism :dollar:| at smartcontract level, send fees to another address | at smartcontract level, send fees to another address |
|spam | :white_check_mark: user pays | marigold will have to set quotas if free <br />**OR**<br /> ask for payment on each transaction request |
| taquito version upgrade | :negative_squared_cross_mark: (if code generation is different, old voting sessions are hidden) | :negative_squared_cross_mark: (if code generation is different, old voting sessions are hidden) |
| smart contract version upgrade | :negative_squared_cross_mark: (if code is different, old voting sessions are hidden, need to upgrade x times) | :white_check_mark: (upgrade once) |

# Implementation

## US-0

### Login





### Home page (we could also replace it with a Menu 2 entries, less code and better navigation)


## US-1

### Configure page


### Creation page



## US-2

### Search page


### Voting page



## US-3

### Results page



---

# Proof of Existence

## Introduction of the problem

Best video so far of the issue and a proposed solution https://www.brightid.org/

A good voting app using it apparently on Ethereum : https://snapshot.org

## Investigation field

Each real person develops a strongly connected graph locally. Making bi-directional connection will strenghen the solidity of the structure. In graph theory, the goal is to create the greatest clique (https://en.wikipedia.org/wiki/Clique_(graph_theory) , https://en.wikipedia.org/wiki/Theorem_on_friends_and_strangers)

If hackers try to created some sock puppets, consequences are :
- new big strongly connected graph clusters. This can be detected and denounced by accusators. If totalHonestPeoplePower > totalDishonestPeoplePower then majority can destroy emergent pirate clusters
- a dishonest cluster trying to connect to the real people. This can be detected by real honest people or just discarded. Example of rules : "a clique gives a voting power to its members", "only clique members can vote for a local clique election"

To strenghen the consensus, I propose to not rely (only) on the virtual social graph for theses reasons :
- family and friend privacy. We are not Facebook
- too virtual, not possible to filter election by location. we lose the *physical proximity* criteria, virtual criteria are too open and let bots to easily occupy this space

Let's add a geographical criteria :
- physical representation. Local check can be done by people not in the social circle of the person. Kind of neighbourhood gang. Incentive to protect the district from foreigners
- local election can be filtered based on local physical clusers. ex : election of regional deputees, alert targeting are easier, ...

## Story game : How to play the game in real life ?

1. Generate a unique identifierthat cannot be stolen (kinda wallet address)
2. Contact a friend via a secure and trusted channel. We recommend physically, otherwise via a messaging app and share you identifier
3. Ask you friend to do the same, and register his identifier into the graph saying that it is your trusted friend
4. Ask you friend to register you as a trusted friend too
5. You have created the first 2-clique of the graph
6. Iterates this with all your friends until exponential growth will cover Worldwide population