Better Voting Mechanism for DAO

[AthrunArthur]

Aragon Nest Proposal: Better Voting Mechanism for DAO

Abstract

Voting could be very complex as a DAO grows.

Currently, the official Voting app only supports using all tokens at a block height as ballots. This may lead to risks that whales may dominate or manipulate the voting result. In the case that the voting result may affect how to distribute new tokens, the whales may get richer. And this is so called the Matthew-Effect. As a DAO grows, the Matthew-Effect introduced by voting may destroy the DAO, instead of making the DAO better.

We propose a through understanding about the current voting mechanism in Aragon. The very basic understanding include how many people are involved in the votings, how may votes are created, etc.. Furthermore, we need understand wether the decisions with most voted tokens are the decisions agreed by most people.

Besides the through understanding, we propose to implement liquid democracy, in which an electorate has the option of vesting voting power in delegates rather than voting directly themselves. According to community, liquid democracy is considered the true democracy for the 21st century, and there are existing efforts about realizing liquid democracy on blockchain, like coalichain, liquid.us, etc.. We believe that liquid democracy could be an alternative voting mechanism for growing DAO.

Deliverables

1. A tech report includes understanding about the current voting mechanism in Aragon.
2. Add liquid democracy in the official voting app, including the smart contract and the frontend to let users benefit from liquid democracy.

Grant size

Funding: $90k in DAI.

Success reward: 30k ANT upon completion of all deliverables.

Application requirements

Team Members

Xuepeng

Doctor of computer system architecture of Huazhong University of Science and Technology, visiting scholar at the University of California, San Diego. Has been a researcher and a developer in Nebulas, a public blockchain.

Yulong

Doctor of the institute of interdisciplinary information science of Tsinghua University, visiting scholar at the University of Michigan and Aarhus University. Has published many papers as the first author in top international conferences such as EC, AAAI and AAMAS about game theory and mechanism design.

Chenmin Master in computer of Zhejiang university, former Dolphin Browser research and development engineer; former Tencent research and development engineer; former Huawei research and development engineer.

The team members are from ASResearch.

Legal

The team is a DAO currently in China using smart contract to manage their payroll.

Burnrate

6 Months of development with 3 team members @ $15,000/month.

Development timeline

The development timeline will be the following one in regards to each deliverable if we are able to get funding by Oct 1st, 2019:

1. Oct 30, 2019 - Crawled all data related with Aragon voting.
2. Nov 30, 2019 - the tech report completed.
3. Jan 15, 2020 - the liquid democracy is added into voting contract.
4. Feb 28, 2020 - the user interface of liquid democracy completed.
5. Mar 15, 2020 - all documents, dev tools related with liquid democracy done.

[izqui]

Thanks for your proposal!

Add liquid democracy in the official voting app, including the smart contract and the frontend to let users benefit from liquid democracy.

Do you have a spec for how you are planning to implement liquid democracy? Implementing unlimited (supporting delegation chains with arbitrary size) liquid democracy is non-trivial (we have tried multiple approaches and have decided to table it for now because of some hard technical challenges)

Also the contract code for one-level delegation has already been implemented by Aragon One and it will be released as soon as the frontend has been updated to support it.

[AthrunArthur]

Thanks for your proposal!

Add liquid democracy in the official voting app, including the smart contract and the frontend to let users benefit from liquid democracy.

Do you have a spec for how you are planning to implement liquid democracy? Implementing unlimited (supporting delegation chains with arbitrary size) liquid democracy is non-trivial (we have tried multiple approaches and have decided to table it for now because of some hard technical challenges)

Also the contract code for one-level delegation has already been implemented by Aragon One and it will be released as soon as the frontend has been updated to support it.

Thanks for your reply. Aragon is really responsive.

I checked those technical challenges and they're quite different from our approach. Although we don't have the spec for now, I will try to explain our approach and the limitation here.

The basic idea is to use Merkel Proof to eliminate on-chain computing on the delegation graph. First, the voting creator need to provide Merkel Root hash in the voting meta-info. The Merkel tree includes each voter's state, like voting power, his/her delegator, wether voted already.

Second, when casting a vote, the voter needs to provide the total computing power and the Merkel Proofs. The contract will read the voter's state (his/her own voting power, his/her delegator, whether voted already) at the specific block height, and hash the voter's state. After this, the contract combines the hash and the proofs, and check if the voter can casting the vote with the provided power.

Third, the contract changes the voter's state, compute the new Merkel Root hash, and store it in the smart contract.

For either creating a vote or getting the Merkel Proof when casting a vote, one should snapshot the delegation graph and the voting status, and build the Merkel tree off-chain. And this can be done in a centralized server or in decentralized manner. Since the Merkel Root hash is already stored in the smart contract, there is no need to worry the correctness of the Merkel Tree or the Merkel Proofs. If one uses wrong Merkel Proofs, the vote will be invalidated.

The advantages of our approach: Basically, all computation is done off-chain, so there is no need to worry about the gas cost on casting vote, delegating/undelegating, or voting/unvoting themselves. The gas cost is constantly proportional to the length of Merkel Proofs.

Also, there is no need to worry about the max delegating level or the griefing attacks.

The limitations: The biggest limitation of our approach is that only one vote can be contained in a block. This is because each casted vote will change the Merkel Root hash in the vote. And the following voters can't be aware of the new Merkel Root hash. Correspondingly, the successors in the same block will burn the gas meaninglessly.

Due to the limitation of voting throughput, the voting period should be long enough. And this shall be common in large scale DAOs.

Another issue is that voters may resist voting because of the possible failed voting. The solution to mitigate voters concern is to provide incentive if their votes are accepted.

Hope the explanation above is clear enough. Please let us know if you still need a detailed spec.

[yeqbfgxjiq]

Liquid democracy would be awesome, however, only allowing for 1 vote per block would be terrible from a ux standpoint. Is there any way to improve upon this?

Also, it sounds like this approach would require users to perform computations off-chain? If so, how would that happen? As is, there is very low voter participation even though all people have to do is open Aragon in a browser and vote. If they had to perform additional steps off-chain I'm concerned that might even further discourage voter participation.

[AthrunArthur]

Liquid democracy would be awesome, however, only allowing for 1 vote per block would be terrible from a ux standpoint. Is there any way to improve upon this?

Also, it sounds like this approach would require users to perform computations off-chain? If so, how would that happen? As is, there is very low voter participation even though all people have to do is open Aragon in a browser and vote. If they had to perform additional steps off-chain I'm concerned that might even further discourage voter participation.

We just figured out a way to mitigate the limitation of 1 vote per block. And this approach only require off-chain computation for the voting creator. The basic idea is to use interval tree to update delegates. We have proved the on-chain computation complexity is O(log n) where n is the number of voters.

As the approach is not that straightforward, we will post a detailed specification here later. Thanks.

[AthrunArthur]

Hi @izqui @burrrata , we just updated our algorithm specification of how to implement the liquid voting. https://github.com/freeof123/liquid-voting/blob/master/fluent.pdf

Please check it and let us know if you find any problem here.

Thanks

[yeqbfgxjiq]

Research Paper

Thanks for sharing, but your paper jumps right into the mechanics without an introduction or high level overview. Can you please provide a high level description of what's going on? This would help readers understand what's going on. It would also provide reference material for the rest of the Nest team so that they have a general idea of what's going on,. This is important because the entire Nest Working Group needs to sign off on applications before they get funding.

Deliverables

A tech report includes understanding about the current voting mechanism in Aragon.

Sorry, but the Nest program does not fund research at the moment. The Aragon CFDAO, however, does fund small scale research endeavors. You can learn more about that program here.

Add liquid democracy in the official voting app, including the smart contract and the front-end to let users benefit from liquid democracy.

Have you designed and specified how this would work?

Do you have a working prototype?

Have you build decentralized applications on Ethereum before? If so, please share code and links to working applications.

[AthrunArthur]

Thank you for your reply.

We will definitely modify our report to be legible. Meanwhile, we would like to reemphasize the breakthrough our algorithm.

We believe that our algorithm solves the liquid democracy problem, from the following aspect:

1. For each voting, we only require O(log n) on-chain time complexity to real-time update and display the voting status, i.e., the votes of each candidate.

2. We require a O(n) time complexity for initiating the algorithm, which can be realized incidentally from each voter’s voting activity.

We are confident with the soundness of the algorithm and will try our best to explain, thought it is not that straightforward. We are glad to discuss and illustrate the confusions at any time. Hope we can keep in touch.

About the deliverables:

As the tech report is not supported, we rearrange our deliverables as follows:

1. The report that introduces the algorithm (with Pseudo code), the illustrations and proofs. An accepted academic paper is considerable if necessary.
2. The official DApp for liquid democracy on Ethreum main net.
3. The front and user interface.

In total, we can reduce our budget to 80k DAI.

About the our decentralized applications on Ethereum, here are several deployed contracts here. https://etherscan.io/address/0x42C84016B5C037F5b60011b32A0F48960b4dd121 https://etherscan.io/address/0x07098fc448CF6FE775e4DcF932F3A5A171e49182#code Another contracts that not deployed yet can be found here, https://github.com/gotoken-io/gttoken-contract

Looking forward to your reply.

[yeqbfgxjiq]

We believe that our algorithm solves the liquid democracy problem

How/when will you know? Have you tested it? Do you have any running code?

About the our decentralized applications on Ethereum, here are several deployed contracts here.

Please at least provide a high level description of what each of these dApps is, why you built it, and how it relates to your current project. Also, do any of these dApps have daily or monthly active users?

[yeqbfgxjiq]

This proposal feels very heavily weighted in research. Closing this proposal due to the fact that there is no running prototype to test the feasibility of this mechanism and that the Nest program is not in a position to fund research. Please feel free to re-apply and/or re-open this Issue if that changes! :)

Also, the CFDAO might be a great place to get some support for initial research and/or to test out the idea.

[AthrunArthur]

Hi,

Sorry for the late reply. We were busy on implementing the smart contract of our algorithm. And we are glad to share with you that our method significantly outperforms traditional methods that are described here. You may check our implementation here. And also feel free to run the tests. Our comparison shows very limited gas usage on Ganache.

Also, we have put our work on arxiv. A peer-reviewed academic paper will be published later.

As I claimed before, we are confident that we solved the liquid voting problem. And now we have implemented it and also evaluated it. That makes us even more confident. That's why we come to you again.

I believe that Nest is trying to funding products on Aragon that may potentially impact the world. A product prototype as attached is what a research team like us can provide. But building a product for end users is beyonds our current plan. We would like to hear further feedback from Aragon and we would consider to further implement the product is the demo received sufficient positive feedback

We understand that Nest is not a research funding as you clarified. However, the research part of the solution is done. We would appreciate the grant to further turning the algorithm into a end user faced production.

Finally, we reached other blockchain communities as we presented our idea on DAOFest, an event hosted by DAOStack and other volunteers. As some other blockchain communities have shown their interests of adopting our solution, I'd like to show our respect to Aragon and Nest since this is the first place we present our idea. Thanks for your consideration and looking forward your final decision.