@phroi
We spent more time to explore possible online voting solutions, the most important reason is we don’t want to add dependence on ZK right now.
So here is our current solution for CKB:
it’s a optimistic way of tally, and the performence of cycles and size is small enough for voting and tally, and it does not need to add any special code change for voting on the consensus layer of CKB node(Activating treasury of course need seperate change for it).
Thanks @chenyukang for sharing the Optimistic Tally!! An overview:
A proposal is a Type ID cell holding a bond.
Vote cells reference the voter’s DAO deposits, which must be older than the proposal. Weight is the deposits’ capacity.
Counting cells certify YES votes in slices of voters, split by lock hash prefix. After the voting period, the proposer finalizes the proposal with at least yes_threshold YES votes.
During the challenge period anyone can challenge with certified NO votes. If NO votes are at least YES votes, the proposal is rejected and the challenger takes the bond. Otherwise it passes.
An administrator config cell sets all parameters, can halt the system and can veto finalized proposals.
Sums are checked on-chain. Nothing proves that every vote was counted, but each side has a reason to certify its own votes. Compared with the other non-ZK designs:
DAO v1.1 tallies off-chain. Optimistic Tally checks eligibility and sums on-chain.
Deposit-Paired Voting (mine) parks deposits under voting logic for an exact tally with revotes, at the cost of migrating deposits and one shared cell. Optimistic Tally reads deposits once, when the vote is cast: they must predate the proposal but need not stay deposited.
CKB Governance by @anihdev is the closest relative: its tally lanes are like the lock-hash slices. Optimistic Tally adds the bond and challenge. It weighs votes by DAO deposits instead of one per wallet.
I’ll be sure to open my questions / doubts on GitHub!
Keep up the Great Work and congratulations on joining CKBA, glad to see your hard work recognized!!
Phroi
Thanks @phroi for reviewing the spec!
Generally, how do you think about this solution?
There are still two things in my mind that we need to investigate how to resolve:
1.We have a requirement that at least one input must have the same lock used with the DAO cell. This may cause some inconvenience for users, and there are also different kinds of locks used for DAO holders.
2. A large DAO holder, custodian, exchange, or colluding coalition may still create a permissionless Proposal paying itself and supply enough genuine voting power to satisfy every configured condition. We may need to introduce a role such as administrator of Treasury (maybe it is a multi-sig lock), which has the power to veto a proposal. So the question turned out we need to construct such kind of group, it acts like a safeguard for the workflow.
IMHO this fair: this protocol doesn’t require to re-deposit, it doesn’t use fancy tech and it tries to minimizes failure points. Kudos to @xjd!!
If it creates troubles for RGB++ users (or generally those whose lock change at every tx), then I would suggest these users to use a compatible wallet just for using this protocol.
If reusing a lock is a perceived security issue for Q-day, then Quantum Purse should give enough peace of mind.
Independently from reviewed projects, my feeling is that voting with money is short-sighted for the very reasons we both pointed out: it works until it doesn’t…
I would personally try to see how a CKBA-based system could work rather than risking hostile takeovers from wealthy CKB holders.
