The crypto community has been wrestling with the realities of collusion and bribery in decentralized governance. Evidence has arisen of EOS block producers swapping votes, and widespread collusion has cropped up in other blockchain systems such as Lisk. Staked voting systems offer an ostensible solution to this issue, where the weight of a vote is proportional to the amount of stake locked up with the vote. This system removes incentives to bribe, but only because it becomes cheaper to directly influence elections with money. Whales, crypto heavy-hitters who own lots of funds, can quite literally tip elections in their favor by using their wealth. A recent analysis of votes on Aragon demonstrates a notable case where a single whale tipped multiple votes against what appeared to be broader community consensus . For blockchain systems to scale to societal use cases, we need to build infrastructure that is resistant to bribery schemes and explicit plutocracy. In particular, by building a mechanism to have robust decentralized identities, with one account provably matched to one human, we can recover many of the properties of existing voting systems in modern democracies. In this letter I make a simple proposal for an identity system on top of Ethereum.
How do we get started with designing such an identity system? Vitalik (the creator of Ethereum) has suggested networks of social trust could serve as identity. This system is roughly how governmental agencies verify identity for example. The California DMV (Department of Motor Vehicles) requires bank or credit card statements to verify your identity as a resident of the state. The government believes that attestations by established companies can verify your identity. (It’s an ironic reflection of America today that “corporate citizens” are needed to attest for human citizens.) Returning to Ethereum, we don’t yet have long established institutions on Ethereum like banks or credit card companies that can verify your identity. (Although this is starting to slowly change with decentralized finance projects where there is now loan history for some accounts on MakerDAO). But nevertheless, we can use Ethereum’s existing infrastructure to bootstrap an identity network.
Let’s start by reviewing how standard staked voting systems on Ethereum work today. Let’s say I hold an Ethereum address with funds. 10 ETH to be precise. In a staked voting system, my vote is proportional to the amount of funds I put at stake on the vote. So if I staked all 10 ETH, my vote would ever worth 10 times that of someone who had only 1 ETH to stake. This creates the rule of the wealthy we discussed above where one wealthy party can tip elections in their favor easily. There’s a second danger in tying identity to accounts with funds. If a network requires votes from accounts with funds, it becomes easier to identify who’s behind those accounts since analysts can gauge proclivities of the true owner from their voting record. Chain analysis tools might be able to identify the voter by matching against real world data or other on-chain records. Remember in crypto revealing that you hold large amounts of funds is a serious security hazard. There have been attacks of people to steal the private keys controlling their funds. Ideally a voting system shouldn’t be tied to proof of wealth in this way.
We instead posit the baseline principle that one human should have only one vote. The challenge now becomes how we can bootstrap a system with one-human/one-vote on-chain and render it robust to bribing attacks. To bootstrap the system, let’s use a simple system of trusted attestation rather than purchase of stake. For me to gain an identity, I need to be attested by 5 trustworthy individuals. Once I have an identity, I gain the ability to attest for others. To keep the system stable, it is important to aim for slow and steady growth. So let’s say that an individual may only attest for 1 other individual per week. Each identity is given one and only one vote in the system. If the core network is grown out carefully, identities could remain sound and not infiltrated rapidly by bots.
The major danger in this type of system is Sybil attacks. Can I make 50 puppet accounts and place them under my control? If I get 5 friends, we could form a trust cartel that prints new identities and tips votes in our favor. We need a mechanism to prevent this. For confirmation, let’s have the system require that a new identity with 5 attestations is voted on by the set of all existing identities. The twist here is that if the vote fails, the 5 attesters will lose their attestation powers for a set period of time, say for a month. Importantly, attesters don’t lose their franchise though. All individuals in the system have earned the right to vote. However by improperly attesting, they have shown that their judgment is in question so they are withheld from attesting to the identity of newcomers. However honest mistakes will happen, so the punishment here is kept intentionally mild. This system offers some safeguards, but voters are lazy and may not have incentive to thoroughly scrutinize newcomers. It’s all too easy to see this system becoming a rubber stamp mechanism. To control for this possibility, we could add a bet mechanism, where voters who voted wrongly in the election could be penalized. This punishment would be mild (loss of attestation privileges for a day perhaps) but might prevent rubber-stamping from proliferating.
In addition, to lower the chance of puppet accounts proliferating, any identity holder is allowed to accuse another of being a bot. A vote is held to adjudicate this accusation. If the vote passes, the challenged account loses its identity and franchise. The attesters for this account lose their attestation privileges for a month once again. The accuser has shown energy and trust, so they gain the ability to attest to 2 individuals for the coming month. This reward does not stack; no individual gains the ability to attest to 3 or 4 or more others. And the privilege is time boxed. This privilege is primarily a mark of trust from the system that serves to provide social signalling value and not any formal authority.
There are a few issues here. For one, a known issue with all voting systems is apathy low voter turnout. For this reason, the system enforces that all individuals must vote within a period of time denoted one epoch (say 6 months). Individuals who fail to vote have their identities revoked and must re-enter the system by gaining attestations once again. Identity brings with it responsibilities and obligations. Citizens (identity holders) must exercise their rights to retain their franchise. This requirement brings our voting system more in line with democracies that require compulsory voting such as Australia.
This scheme is somewhat similar to existing proof of stake systems, but the critical difference is that there is no token. There is no “identity coin” that can be held by funds. This design is on purpose since there should be no easy mechanism for the wealthy to subvert the system. By design, the only rewards in the system are increased and decreased trust. These rewards are strictly time boxed and limited and should only serve as auditable social sign for informing future voters. In addition, these addresses can be chosen so they hold no funds. This lowers the incentive to violently steal the private keys that control a particular address.
It’s worth noting that our current system doesn’t solve the same problem as recent proposals for anti-collusion-infrastructure Such systems have mechanisms that make bribery challenging by allowing users to invalidate their known keys and swap to new keys secretly. This system means that a bribed individual can always cheat the briber by invalidating their key before they vote. At present though, the scheme depends on the presence of a trusted aggregator who gathers up all key operations and produces a SNARK attesting to their work at the end. It appears that the single trusted operator could be swapped to a m-of-n multiparty scheme for some additional robustness. Such a collusion resistance scheme like this could be layered on top of the robust decentralized identity scheme proposed in this note. Composing these primitives could lead to a more robust voting mechanism and would be an interesting topic for future research.
The smart contracts for the design proposed here will take some effort to design correctly, but in principle should be possible to design without too much effort. If the network is bootstrapped carefully so that the chain of trust isn’t violated, this identity system could serve as a resource for the entire community.