owned this note
owned this note
Published
Linked with GitHub
# Dot voting
[Dot voting](https://en.wikipedia.org/wiki/Dot-voting) consists on multiple agents being able to vote on a same issue with multiple options, but where each agent only gets a certain amount of votes. An agent can vote as many times as they want for the same option, but summed their votes can't exceed the number of votes they have.
This is a less consensus, more "flexible" way of signaling importance of interest. It presents some of the same challenges as traditional voting, so I'm going to use it as an example.
Technically, this is a reusable zome that does not need any membranes (maybe one to make sure that no two agents belong to the same person, like social triangulation, but unlikely because we are already filtering who can vote on the side of the proposer). It can be used in different contexts and DNAs.
>To transform this into normal "majority" voting, we should:
>1. Make each vote its own DNA.
>2. Pass in as properties of the DNA the list of nodes that will play the role of "ballot boxes".
>3. Make a membrane that allows only the people that are in the census list,
>
>And we also still need a mechanism to anonymize the votes, which I can't think of unless we *trust* the ballot boxes to never disclose our identity (maybe ZK-snarks could be used here)
## User stories
* Any agent should be able to propose a vote, specifying a list of options, list of authorized users to vote, a max number of votes for each agent and a time limit.
* An agent authorized to vote should be able to vote for the options they want, but those votes should never exceed the number specified by the proposer of the vote.
* The proposer of the vote should be able
## Entry structure
This first anchor type is from [holochain_anchors](https://github.com/holochain/holochain_anchors)
```rust
Entry "anchor" {
struct Anchor {
anchor_type: String,
anchor_text: Option<String>
}
}
Entry "vote_proposal" {
struct VoteProposal {
proposer_address: Address,
// These can either be titles for the options or
// addresses of entries in the DHT for more complex data structures
options: Vec<String | Address>,
authorized_agents: Vec<Address>,
max_dots: usize,
// Just for info
closing_time: Timestamp,
// For actual validation purposes
closed: bool
}
Links: {
agent_id->vote_proposal, link_type: "proposed_vote"
agent_id->vote_proposal, link_type: "voter"
// The tag in this link is where the vote info will be stored
vote_proposal->agent_id, link_type: "vote"
}
}
```
The tag inside the vote_proposal will be a serialized struct of this form:
```rust
struct VoteTag {
vote: {
voter_address: Address,
vote_address: Address,
options_voted: {
[index_of_option]: [number_of_votes_for_that_option]
}
},
proposer_signature: Signature,
}
```
With this design we optimize for query efficiency on the "get_all_votes_for_this_proposal" function, but it will be a little slower for a "get_all_votes_that_this_agent_has_made" (you have to make more hops).
## Flow of voting
To know when a vote is valid or when it is not, we are going to use the proposer's time, as they are the valid authority that everyone trusts when accepting to participate in the vote. To make sure that the proposer's time was not passed when a vote was cast, the proposer will need to sign the vote.
This is how it would work:
1. A proposer creates a vote proposal.
2. A voter inputs their vote for that vote proposal, and sends it to the proposer.
3. The proposer checks if the vote proposal is still not closed. If it's closed, it rejects to sign the vote.
4. The proposer hashes the info, signs it and returns the signature to the voter.
5. The voter creates the vote with `add_link`.
> This method has the downside that the proposer has to be online at all times for the votes to be signed, maybe there are other patterns which do not require it.
## Entry relationship diagram
```mermaid
graph TD
subgraph postszome
subgraph anchors
all_votes
end
subgraph agent_ids
alice_id
bob_id
end
subgraph vote_proposals
vote0
alice_id-->|proposer|vote0
bob_id-->|voter|vote0
alice_id-->|voter|vote0
vote0-->|vote|alice_id
vote0-->|vote|bob_id
end
all_votes-->vote0
end
```
## Validation
### Entries
* `anchors`:
* Create valid if the agent_address that is creating it is signing the entry
* Update or Delete is not valid
* `vote_proposal`:
* Create or Update is valid if the agent_address that is creating it is signing the entry
* Delete not valid
### Links
* `vote`:
* AddLink: valid if:
* The agent_addres in the anchor from which we are linking is signing the entry
* The signature of the tag is from the proposer address of the vote proposal that is the base entry for the link, and it's signing the hash of the "vote" portion of the tag.
* The indexes of the options inside the votes do not exceed the options vector length in the vote proposal that is the base entry for the link.
* The vote address is equal to the base entry address
* The sum of the votes is less or equal to the maximum allowed votes in the vote proposal
* There is no other link from this vote to the same voter address
* RemoveLink not valid
Future optimization: remove vote_address and voter_address from the tag, requires that the signature is made with those properties inside the content that's hashed and then signed.