On-Chain Tally: DAO v1.1 Limits and a Deposit-Paired Voting Proposal

[phroi]

Hey @david-fi5box, glad it picked your interest!

@david-fi5box

The voting status is placed in the vote meta cell. This will cause cell competition issues; if two people vote at the same time, one of them will inevitably lose.

Yup, thank you for picking it up!! It was briefly mentioned in Tradeoff section, but merits a deeper analisys:

1. State contention is not a road blocker for voting at the current levels of participation, worst case scenario a user just need to sign again a tx
2. State contention tho is an issue for DoS potential: attacker can keep busy the VoteMeta cell, effectively denying participation of others to the vote

As you are well aware this is a problem felt by deeply by the entire ecosystem, so much that we had over the years attempts over attempts to fix it, namely Intent Cells, Open Transactions and (weird but intriguing) PoW gated access to cells:

• PoW gated access to cells is still in the ideation phase, needs research
• Open Transactions would be the cleanest solution: we have working designs, but what’s currently lacking is EcoSystem agreement.
• Intent Cells are the best candidate: user transforms VoteRightOwner into an intent cell by using a special lock on it (very similar to Delegation in this model) and an aggregator makes sure that his vote is included.

Side Note: user can choose which Lock he prefers, we don’t need to force everyone to use Intent Cells (nor Delegation OFC). Again, if he so prefers, a user can just keep signing again until his vote is included.

@david-fi5box

The structure of voting transactions is too complex, and the gas fees would be extremely high.

Not really a thing:

• VoteMeta just store little constant information: not who voted, but what is the aggregated result and small Vote meta information
• VotingRightOwner stores more information: there must be an entry for each vote participated to. That said, this entry can later on be garbage collected once the vote ends, so it doesn’t grow indefinitely and it’s proportional to the number of active votes at a certain moment.

@david-fi5box

Existing NervosDao staking cells must undergo a conversion.

We have the following trade-offs:

1. Want to keep current deposits? → Fully off-chain system, doable, tricky part is to make sure it’s auditable, transparent and operator resistant.
2. Want to have an elegant simple verified on-chain system? → You need to put a special lock on those deposits, hence withdraw and re-deposit.

Anything in the middle and you get way more complexity than you bargained for.

Yesterday I was explaining @chenyukang the reasoning underpinning the presented design:

@phroi

what seems most important is control over the backing deposit’s spend path. On CKB, the lock script controls who can spend a cell. A read-only reference can identify a deposit, but it does not give the governance rules control over that deposit.

If the deposit stays under its original lock, the owner can still move it through the normal DAO withdrawal path outside the voting state machine. Then the protocol cannot reliably:

• keep the deposit paired to one controller,
• prevent it from exiting through another path,
• make release follow the voting lifecycle.

That is why the deposit-paired design parks the backing deposit under voting-right logic instead of leaving it only as a reference. That tradeoff is also where the stronger on-chain guarantees come from.

Back to us

@david-fi5box

This means that NervosDao-related ecosystem tools such as Neuron, JoyID, and CKB Explorer would all need to be adapted, which is completely impractical.

• Neuron: say App5 was to decide to bring Neuron up to speed, then Neuron users would be able to vote via CCC: [FR] Allow CCC DApps to use local Signer + Light Client · Issue #3438 · nervosnetwork/neuron · GitHub (Currently Neuron is clearly leading the races: [Bug Report] AppImage broken on modern distros: `dlopen(): error loading libfuse.so.2` · Issue #3434 · nervosnetwork/neuron · GitHub)
• JoyID: you just use the Voting DApp via CCC and Light Client, this DApp doesn’t need any special treatment.
• CKB Explorer: explorer can show the transactions, but it shouldn’t really try to interpret the logic for every protocol.

Thank you for the feedback @david-fi5box, keep it coming

Phroi

PS: If you prefer, I can transform this design sketch into code and we can test it out together