Have fun with failures

CKB Community Fund DAO
1

Nervos is a big venture.
The community DAO proposals are small ventures.
Exciting ideas will pop up, some will transform into actions.
Many will fail.
Don’t be scared of impending failures, that’s part of venture life.
Don’t let the fear of scams put down the spark of enthusiasm.
Learn how to distinguish villains and good ones in this wild west.
Don’t forget it’s a DAO:
bottom-up, not top-down,
anonymous reputation, not KYC,
bazaar, not cathedral.
Reality only changes for actions.
Actions come with success,
and failures.
Have fun with failures, witness the birth of town.

12 Likes
2

fail up!

Hello friend I can’t make a new post here but had an idea

On-chain voting in Nervos DAO

Nervos DAO voting on-chain is needed for the Nervos Network to be a decentralized and sustainable blockchain network.

This can be used Nervos DAO, it uses the cell root field from the block header proposed in the next hard fork.

There has to be room for optimization, thanks in advance.

It still needs a escrow mechanism for the CKB (or other assets) during voting.

  1. A cell is created for each proposal.

  2. Everything is inside a type script, lock script always returns 0. Anyone can use the cell.

Data structure

epochVoteStart: When voting begins, only deposits locked in the DAO at this time can vote

epochVoteEnd: When voting ends, the vote totals are compared and pass/fail action taken

proposalHash: A hash of the proposal, unique identifier

votePassPercentage: percentage of “Yes” votes for proposal to pass

voteAmountMinimum: minimum number of votes required for quorum

voteAmountYes: total “Yes” votes

voteAmountNo: total “No” votes

voteTreeYes: optimized sparse Merkle tree https:// github. com/nervosnetwork/sparse-merkle-tree/blob/master/SMT.md to store proof of all DAO deposits voted “Yes”

voteTreeNo: optimized sparse Merkle tree https:// github. com/nervosnetwork/sparse-merkle-tree/blob/master/SMT.md to store proof of all DAO deposits voted “No”

A vote
Each DAO deposit is secured by possibly a different lockscipt. Ownership of a DAO deposit can be verified through loading the code of the lockscript repeating the same process from verifying a spend, using the proposalHash as what is signed (instead of tx data) for “Yes” vote and a bitwise negation of proposalHash for “No” vote.

Procedure

  1. proposalHash is created
  2. epochVoteStart begins
  3. Voters sign to communicate their votes
  4. (Possible) Aggregators collect votes
  5. Transaction is created to vote
    -A block header during epochVoteStart is loaded
    -State proof inside state root is verified for each DAO deposit
    -Signature is checked for each deposit
    -Exclusion proof is checked (Deposit must not exist in the other voteTree, i.e. exclusion in “No” tree for “Yes” vote)
    -Vote is added to voteTree and tree root is updated through proof
    -If voteTree value is changed, amount is added to voteAmount (if deposit already voted then root won’t change)

Ending voting
Someone loads a block header from epochVoteEnd (can only be loaded if epoch has started) and calls a function which compares voteAmountYes+voteAmountNo to voteAmountMinimum and voteAmountYes / (voteAmountYes+voteAmountNo) to votePassPercentage

Vote change/removal

  1. Same signature checking process
  2. Verify voteTree sparse Merkle tree proof for the deposit
  3. Calculate voteTree root to remove vote
  4. Include vote in the other voteTree (if vote is changed)
  5. Update amounts

Competition for the cell
Many users may try to update the vote cell. Signatures and proofs can be collected and submitted by an aggregator. Between state transitions only the sparse Merkle tree proofs would change.

Idea about state root

It would be useful for the state root to include the epoch when a cell was created. In this case, coin age could be an input to voting power.

2 Likes