Establishing Election Policies
In order for an election to operate smoothly and relatively predictably, we need to agree on a set of policies ahead of time ranging from node membership to handling discrepancies. These policies are part of the protocol and must be implemented in any EIP compliant system.
Personnel Policy
This policy largely handles vetting people who are involved in operating the election process. People play one of two roles. They are either an observer or they are a registrar. The registrar is the more stringent of the two because they vet everybody and issue ballots. The observers verify processes. The vetting registrar also vets voters, token assignment registrars and observers
Dissemination Policy
Election information is available immediately. At what point should this information be released to the public?
The canonical model for elections has a relatively short collection time for voting, and then releases the result at the end of say, one day. The general principle behind this is that there is a belief that should the state of any races be published immediately, it might affect the outcome of the election. People are sad and get discouraged if their candidate is behind, and all of that.
However, there is another way to look at this. Whatever the time window that exists between vote collection and the end of the election, that offers a prime opportunity for fraud. Nefarious election managers can calculate how many votes they need to win, etc. We’ve all witnessed this in broad daylight for the last two elections. Thankfully, this type of scenario is not even possible with EIP.
It can also be argued that say you were to receive this data in real time, that’s an indication that you need to gather even more people to vote, since it is a voluntary process.
So it’s a trade-off. The dissemination policy specifies where along the temporal spectrum of choices information is to be disseminated and to whom.
Vote Acknowledgment Policy
This applies only to electronic ballots. After the voter receives their vote on their device, they must either acknowledge it or challenge it. This creates three possible states for the vote:
- acknowledged
- challenged
- unacknowledged
The policy will spell out what to do with a vote in this situation.
Challenges to a Vote Result
If a challenge occurs, it's hard to imagine how the voter's reported vote could differ from their selection, but that option is offered nonetheless. A challenge will trigger a Discrepancy Report and the voter should seek a registrar immediately.
Unacknowledged Vote Result
If a voter simply provides no indication either way, the vote enters an unacknowledged state. In this case, the policy needs to specify whether or not to count that vote.
If no policy is specified, the default behavior is to only count acknowledged votes.
Discrepancy Policy
What happens if we do discover errors or potential fraud? Do we adjudicate the defective ballots immediately or do we kick the offending node off the Network? It’s a crime to interfere with elections- these people need to be arrested. These are the types of questions addressed by this policy.
Special Needs Policy
Some voters cannot vote easily, including disabled, and the elderly. This policy specifies how to support these voters.
Vote Alteration Policy
Although it’s not generally thought of as being sound election policy, some elections may offer the ability to alter a vote once it has been submitted under certain special circumstances. For example, nobody wants to turn away a blind voter who claims they made a mistake.
Node Participation Policy
Recall that a Distributed Ledger Network requires multiple nodes. These are computers hooked up to the network, operated by people who run software on them. Do these people and machines need to be vetted? In general, no, other than they need to be people coming from opposing political views. You heard that right. Like it or not, you’re going to be forced to have to cooperate with people you disagree with. That’s exactly how elections are to be conducted.
But don’t these machines need to be verified and the software inspected and the networks and all that? It is expected that some of this will go on due to best practices, but in the end, all we are looking at is the data output rather than the machines or the software that produces it. If all the data matches, we are good to go. To be blunt, such scrutiny is a waste of time and money
Disaster Recovery Policy
This policy specifies what to do in case of an emergency or a system failure. If a distributed ledger is used, do we shut down all the others until one of them recovers or do we continue on? Or do we notify the other network nodes?