Holochain Forum

Global State (Voting hApp)

I encountered the idea of a voting hApp.

What I’m wondering though, is how you would deal with the “Global state” of the voting result. So basically at the end you have the decision arrived at by all the combined votes, which is the same for everyone.

How would that be easily accessible by everyone?

Hi @raphisee, I am working on voting apps.
Let’s talk about this also.

1 Like

That is a good question. Probably some Hashgraph-style (beware the patent :neutral_face:) “Gossip about Gossip” solution.

Another interesting question is: How do you allow for an anonymous vote?

1 Like

Global state is a little hard because in a way it doesn’t exist in this type of system.
Each agent really only ever has their own local state / history.
For something like a voting system you would probably need to do something like have a window of time where votes could be cast and only votes committed to the dht in that window would be counted.
You would then need some trusted source of time (like a trusted time server) or some other way to prove that the vote was cast in that time window.

The reason for this is Holochain works on eventual consistency.
Imagine yourself as an agent that is part of a big network trying to do a vote.
It’s very possible that a vote would come to you asking to be validated after this time window has passed. However it may have been actually committed to the dht inside the window.
In this case you would still want to accept it and update your “local state”.

1 Like

Hmmm, maybe in such a case - where you don’t need super high precision (as in: “You can vote for 24h, until midnight”) - we could just accept that if you enter your vote so late that it doesn’t reach enough notaries before the deadline, you are out of luck.

Then one could simply design the UI to only accept a vote (and show the countdown accordingly) up to one minute prior to the deadline. This would give Holochain a full minute to verify the transaction.

What I am trying to say is: In many cases we might not have to solve the problem and instead just avoid it. :sweat_smile:

1 Like

Thanks for your replies and thoughts.

I think I have an answer that could work quite well.
Part of the problem is that you usually want the vote to be cast anonymous, yet the results verified and trustworthy.

Maybe I was thinking that each vote would be an entry on the dht, which would create the problem with the global state of the outcome. But what if the answer of the question we are voting on is actually the entry. And each vote is just a participants signature. Then everyone can look at the answer entries (Yes, No, Abstention), count the signatures and thus see the results.

Now the question is, how do we verify that each participant has the right to vote, while still being anonymous. That could be built into the membrane of the happ, that you can’t even join the network without a valid Passport for example.

The anonymity could be achieved by creating a new private key for each voting-session or even each answer we give.

Considering the time window, that raises the question, if it’s possible to have an invalid signature of an entry, if it wasn’t signed in that time frame…

Does that even work in Holochain, that you can go to an entry and sign it without yourself being chosen as a validator and to store it? Guess I have to think a bit more on it. It’s too late here in Switzerland to think deeper :wink:

1 Like

I like this conversation; a lot of good things are already being uncovered. Anonymous voters with new keypairs are especially interesting. Just want to address one question, then ask a few more.

There are two kinds of signature on an entry:

  • validation signature, created by the DHT nodes holding the entry,
  • provenance signature, created by the authors of the entry.

Because entries with the same content are all de-duplicated (no matter how many people create them, they all go to the same spot), the provenances (author signatures) end up being collected on the one entry. So ‘signing’ an entry would be as simple as writing it to your own source chain, then publishing it to the DHT. Double-votes are prevented by having validators audit the source chain leading up to the vote and making sure there are no other entries written with the same referendum ID.

Now for the questions!

  • Anonymity is a tricky issue. What you want to do is prove that you have a legitimate ID, without revealing your actual ID or linking it to your ballot. Most of the thoughts I have involve third-party authorities, which might be okay and it might not. What sorts of concerns do you all think might show up, and how do you think we could tackle the technical problem of ensuring anonymity and legitimacy?
  • What would ‘good enough’ consistency look like for different voting scenarios? When would it be okay to be a bit vague/forgiving with the voting deadline, and when would it be absolutely catastrophic?
  • With votes as public DHT entries, I could see early votes influencing later votes. What scenarios might require secrecy until polling closes, and how could we implement them using some sort of privacy mechanism (private entries, node-to-node messaging, encryption)?
1 Like

The issue here is who’s time?
You might have a rule that says must be before midnight but I could change my machines time and it would be still a valid entry on my chain. If your rule is only accept an entry if it’s received before a certain time from an agents perspective then you end up in a situation where different agents will validate / reject the same entry depending on how long it takes an entry to get to them.

I think for this you would need some sort of trusted time server that could sign the entry with a trusted time when it’s received. Alternatively I know @wollum was talking about proving time using functions that mathimatically would take a minimum amount of time to complete even on worlds fastest computer.

1 Like