Breaking down Proposal ID 11 - New Voting Mechanism in plain language...
Purpose
To define proposed functional and non-functional requirements for a new voting mechanism as part of the NDC Voting Framework (NDC VF).
Assumptions
What is a Sybil Attack?
Imagine you're in an online game where you're playing against other players. A Sybil attack is when someone creates many fake accounts to make it seem like there are more players than there actually are. These fake accounts can be used to cheat or manipulate the game because they're controlled by the same person. It's like one person pretending to be lots of different people to gain an advantage unfairly.
Proposal
The proposed voting mechanism would calculate voting power for an account based on two things: stake and transaction history.
Quadratic Weighted Voting With Threshold (QWVwT)
What is Quadratic Weighted Voting with Threshold?
Quadratic weighted voting with a threshold is a system where each person's vote counts more if they've contributed a certain amount, and if they haven't reached that threshold, their vote doesn't count at all.
Imagine you and your friends are deciding on what game to play at a party. In this system, only people who have brought snacks to share get to vote, and the more snacks they've brought, the more their vote counts. However, if someone hasn't brought any snacks, their vote doesn't count at all.
So, let's say there's a rule that you need to bring at least two bags of chips to get your vote to count. If you bring two bags of chips, your vote counts a little. But if you bring three bags, your vote counts even more. However, if someone shows up without any snacks, they don't get to vote at all, no matter how much they might want to play a certain game.
It's like rewarding people for contributing to the group and making sure that everyone who wants a say has to pitch in somehow.
In an ideal QWVwT system, QWVwT helps prevent a plutocracy from developing by ensuring that everyone's influence is based on their contribution rather than just their wealth or resources. In this system, the power of an individual's vote is tied to their level of participation or contribution, rather than their financial or social status.
By setting a threshold that requires a minimum level of contribution for voting rights, the system ensures that decisions are made by those who actively participate and contribute to the community or organization. This means that individuals cannot simply buy influence or control through wealth alone, as their voting power is directly tied to their involvement and contribution.
Additionally, the quadratic weighting aspect ensures that the influence of highly active and contributing members is amplified, but not disproportionately so. This helps to balance the distribution of power and prevent any single individual or small group from dominating decision-making processes.
Overall, quadratic weighted voting with a threshold promotes fairness, inclusivity, and meritocracy by rewarding active participation and contributions, rather than allowing disproportionate influence based solely on wealth or status.
Transactions
The proposal intends to use transaction history as a means to determine level of activity where one transaction/month achieves maximum number of available activity power points (20). Idea here is to incentivize community members to actively participate in the development of the NEAR ecosystem.
Calculating Voting Power
As is, proposal 11 calculates voting power by combing staking power + activity power. The proposal intends to use quadratic weighting for staking only.
Staking power = 1000 + sqrt(stake - 1000)
Activity power = 20 for every month that the account has at least one transaction.
Staking includes liquid staking and liquidity pools in addition to general staking (e.g. to a poolv1 contract).
In order to be eligible for activity power, an account must have staked at some point in its history as of the snapshot (state of chain at given point in time which provides the data that will be used for the calculations).
Two additional calculations are part of the proposal that puts the threshold/activity at 100/10 or 5000/25. Each changes the potential distribution of potential votes
What would my voting power be?
Let's work out an example to see this in action. Say I have an account - myaccount.near that is staking 10000 NEAR, is one year old (12 months) and has at least one transaction during six of those months.
stake power = 1000 + sqrt(10000 - 1000) = 1095
activity power = 6 * 20 = 120
Total: 1215
Note the 1000 threshold. If I had only staked (at some point) 10 NEAR, then my staking power would be 10 for a total of 130.
There is a voting power calculator available if you want to check out the voting power you'd get for your accounts.
Considerations
By introducing rewards for activity and quadratic reduction mechanisms the proposal adds incentives for multi-accounting i.e. Sybil attacks. The proposal separates discussion on attacks on quadratic reduction and on activity rewards as follows:
Quadratic Reduction
In quadratic systems, voting power increases quadratically with the number of votes, thus a large number of fake identities could have a disproportionate impact on the outcome.
In addition to the Sybil issue of multiple accounts - that situation can arise if there are cooperative groups who share the same incentives in the NEAR ecosystem for every voting subject. It could be centrally controlled accounts or different stakeholders of a single entity (e.g., members of a collective).
For example - consider an attacker leading a collective group of several accounts with more than 1000 NEAR token held on at least one of the accounts (threshold).
Attacker could distribute stake among the other accounts prior to the snapshot, ultimately ending up with more voting power. Let's see it in numbers:
Group of 10 accounts with one having 10000 NEAR staked, the others all with 500 each. Assuming no activity, voting power of the main account would be 1000 + sqrt(10000-1000) = 1095. Voting power of other nine accounts would be 500 each. Total voting power as a collective group = 5595.
Now, assume the main account, anticipating the upcoming proposal, redistributes stake prior to the snapshot so that all accounts are just below threshold (999). Attacker sends 499 to each of the other accounts to stake bringing them to 999 each = voting power of 8991. Main account would now have voting power = 1000 + sqrt(5509 -1000) = 10058 - almost double the original.
Attacker can not optimally distribute his stake among controlled accounts without knowing the exact threshold. Optimal will be distribution on equal chunks close to the threshold as we consider acquiring of every account has non-zero cost. Stake needs to be distributed before the snapshot date hence prior the threshold publication (and actual agreement on the threshold).
Multi-accounting is a violation of NDC Fair Voting Policy. Users do need to acknowledge compliance with policy. The proposal does not suggest implementation of any technical solutions.
Activity Rewards Gaming
Additional voting power can be gained through multi-accounting or bots (both are violations of NDC Fair Voting Policy).
Bots or affiliated accounts that will stake NEAR tokens and perform transactions every month can introduce Sybil attacks. The proposal suggests that bots are desirable for the ecosystem (e.g. arbitrage bots that decrease slippage) and that benefit outweighs their potential influence in any election where their voting power may be capped at roughly 5% of overall voting power based on an assumption that bot accounts do not stake many tokens.
Oracle
The proposal identifies the need for an Oracle to provide the data necessary for the voting calculation.
What is an Oracle?
Imagine you're playing a game with your friends, and you need to know the weather outside to decide what game to play. But you're inside and can't see the weather directly.
Now, let's say there's a special friend called an "oracle" who can look outside and tell you what the weather is. The oracle is like a bridge between the game you're playing inside and the real world outside. It can provide information from the outside world to the game.
In the world of blockchain, an oracle is kind of like that special friend. It's a way for blockchain smart contracts (which are like rules in a game) to get information from the real world, like the current price of a cryptocurrency, the outcome of a sports game, the temperature outside, or in this case the data necessary for the voting calculation,
So, a blockchain oracle helps smart contracts make decisions based on real-world information, just like your special friend helps you make decisions based on the weather outside.
The proposed oracle is:
- Pseudo-Trustless: Even though there's a level of trust involved, it's minimized as much as possible. We want to make sure the system works without having to trust any single entity completely.
- Optimistic: An oracle is like a trusted source of information. The term "optimistic" suggests that we're hoping for the best outcome from this oracle. It provides data that we're optimistic is accurate and reliable.
- Merkle Proof: way to show that certain data is included in a larger set of data without having to reveal all the details. "Custom" means we're tailoring these proofs to fit our specific needs for the voting process. It might suffice to reduce this to a post on NEAR governance forum for sake of simplicity.
How Does a Merkle Proof Work?
Imagine you have a big family photo album with lots of pictures. Now, your friend asks you to prove that a specific picture of your family is in the album without showing them the whole thing.
Here's where Merkle proof comes in handy. Instead of showing the entire album, you can take a few special pictures from the album, like the cover page and a few pages in the middle. Then, you can create a special list called a Merkle tree, where each picture is connected in a specific way, kind of like branches on a tree.
Now, to prove that the picture your friend wants is in the album, you don't need to show them the whole album. You just show them these special pictures and the Merkle tree. By looking at how the pictures are connected in the tree, your friend can be sure that the picture they're looking for is indeed in the album.
So, a Merkle proof is like a special way of proving that something is part of a bigger collection, without having to show the whole collection. It's really useful for things like verifying transactions in cryptocurrencies or making sure data hasn't been tampered with.
The proposed oracle would consist of:
- Indexer: responsible for collecting the data necessary for the snapshot. It would do this by processing each block in the chain until it hits the desired snapshot point (based on block timestamp/count of block confirmations -> block that receives 103 confirmations before 00:00 PST on 17.12.2023.). Intent would be to parse lockup accounts to retrieve tokens staked through non-native mechanisms whenever technically possible. The final data snapshot at that point would be saved to the Interplanetary File System (IPFS).
- Data Processing Script: Responsible for processing data collected by the indexer and provided by the snapshot. It would sift through the data getting NEAR balances, NEAR staking amounts, transaction count and account age for each account. A Merkle proof and ability to verify it would be provided and the account data would be prepared for an Oracle smart-contract to provide it on-chain.
- Oracle smart-contract: Responsible for storing required data of each account with ability to challenge snapshot. Should be able to add account data in batches, read data for each account, and provide ability to challenge validity of the snapshot. It will have a view method that provides the data for each individual account required by the voting smart-contract.
Oracle development is likely to be outsourced. Anyone can send NEAR tokens to challenge the Merkle Proof and voting would stop if a threshold of 1000 NEAR tokens is reached (optimistic approach).
What is IPFS?
Imagine you have a big box of Legos, and you want to share them with your friends. Normally, you'd have to make copies of all your Legos and give them to each friend. But with IPFS, it's like you're sharing your Legos by giving your friends a special map that tells them exactly where to find each piece in your box.
In technical terms, IPFS stands for InterPlanetary File System. It's a way of storing and sharing files on the internet, but instead of relying on one central computer to hold all the files, IPFS spreads them out across lots of different computers all over the world. Each file gets its own unique address, called a hash, which acts like the map to find it.
So, when you want to share a file using IPFS, you just give someone its hash, and they can use that to find the file no matter where it's stored. It's kind of like having a big, decentralized library where anyone can find and borrow books from anywhere in the world!
Voting
- Multiple votes: Users must be able to cast a vote multiple times (once per proposal/proposal-part), but for multiple proposals.
- Vote-changes: Users must be able to change any of their votes during the voting period.
- Multi-part Proposals: Users must be able to vote on different distinct parts of a proposal.
- Privacy: votes must be cast anonymously through a zk solution or a private shard. Exact design of the privacy solution TBD.
Voting Timeline
Proposed voting timeline/actions include:
Week 1 - Start of the week:
- Snapshot taken and published on-chain.
- Start of candidacy submission.
- Start of challenge period for the Merkle proof.
- Publication of the challenge details for the community on the governance forum.
Week 2 - End of the week
- End of challenge period for the Merkle proof.
- Confirmation published on-chain.
Week 4 - End of the week
- Close of candidacy submission.
Week 5 - Start of the week
- Election starts.
Week 5 - End of the week
- Election ends.
Week 6 - Start of the week
- Beginning of onboarding period (2 weeks) for newly elected cadency
- Restart of the election in case of quorum mismatch or other failure.
My Analysis and Comments
While I acknowledge and commend the effort/work that went into putting the proposal together, as is, not sure how anyone could make an informed vote which perhaps helps explain why there are currently only 46 votes of the 436 required.
In no particular order, issues I have with the current proposal - and of the proposal process in general:
- The proposals I've seen in general (this and others) have so many component parts to them that even if one supports one part of it, they risk voting in favour of something that has parts they do not support. The entire mechanism needs to either distill one proposal to one idea or provide the means to vote on each sub-proposal of a proposal separately.
- In the case of multi-part proposals, needs to be clear whether all parts must pass in order for the entire proposal to pass or if component parts can pass without the entire proposal passing.
- The quadratic formula as presented does little to prevent plutocracy. As it is based on staking it is 100% attributed to wealth vice contribution. If the goal is to prevent plutocracy, then all forms of wealth contributing to voting power need to be avoided. That might suggest activity is actually more important, but even then, one's transaction history depends on how much money one has to transact with.
- Activity being a measure of one transaction/month is a pretty weak assessment of contribution to say the least. In fact, there is likely very little correlation between a transaction and some kind of actual contribution beyond being shown to have done at least one thing in the ecosystem each month. That could be something as simple as logging into a dapp or recreating one's account in a wallet - not sure how that is a measure of actual contribution.
- This proposal doesn't do anything to address Sybil attacks. It's unclear to me, but if it is proposing to shift away from IAH SBT completely then there is actually no gatekeeper at all attempting to determine if one account = one individual and that one individual does not vote with multiple accounts. Would suggest this proposal actually makes it easier to conduct Sybil attacks.
- Those likely to engage in Sybil attacks or other nefarious activity are likely not concerned with abiding by NDC Fair Voting Policy.
- The idea that bots don't contribute too much to the problem based on an assumption of how much they stake completely hand waves away the issue and opens up a vulnerability that someone is sure to exploit by simply giving their bot some NEAR to stake.
- The whole idea of needing an Oracle introduces a level of complexity that I'm not sure is even required. Why can't we simply use a Graph or SubQuery or native indexer subgraph to simply retrieve the required data in real-time. The results of those subgraphs/indexing are essentially snapshots and concern of data validity returned from a decentralized Graph subgraph would not be much of a concern in my opinion. Maybe I'm missing something here.
- It is stated that the activity rewards are meant to incentive/reward accounts for continuous activity. Again, not necessarily any correlation between one account transaction/month and any meaningful contribution to the ecosystem.
- The privacy part of all this is important. Votes need to be provable (during and after the election) with no knowledge divulged during the election and questionably after as well to prevent future harassment/manipulation. Simply put, we need to know a valid vote was cast by a valid person for a valid candidate. That's it.
Recommendations
Do not believe this proposal is ready for consideration or to pass. Luckily, doubt it's going to reach quorum anyways and have to say I'm skeptical that the 46 people that voted actually comprehended what they are voting in favour of (or perhaps they are part of one of the collective groups described as an attack vector in the proposal?).
Some recommendations for a future proposal:
- Write it at a level more people can understand and that is coherent. If there are technical terms, don't assume everyone is going to understand them. Include definitions and expand on abbreviations. Include examples.
- I'd rather vote on several succinct proposals asking to support one thing than one proposal trying to encapsulate many things requiring decision. If one is dealing with multi-part proposals, one option would be to have an overarching proposal that does not pass unless all or some of its sub-proposals pass.
- At minimum, the quadratic voting formula presented needs to include activity along with staking not in addition to. I think it's ok to say that staking represents ecosystem commitment and that activity represents contribution, but in the case of activity - believe we need to have something more robust than one transaction/month to determine actual activity in the ecosystem.
- More fully explain requirement for an Oracle to provide the needed data vice leveraging already indexed data and/or available subgraphs on decentralized chains.
- Better explain why this proposal is superior to IAH SBT to prevent Sybil attacks. Do not believe there is a clear case here that it is.
- Validate or invalidate the assumptions provided (pulled out of/inferred from the original proposal).
