Building Governance Enhancement in Smart Contract Layer

[dusmart]

As @EdgeDLT said in https://github.com/neo-project/neo/issues/2598

Currently there is no incentive for a voter to choose a node outside the top 21 council members. Doing so would sacrifice GAS rewards. This makes it very difficult for a new node to enter the council if they do not control enough NEO to reach the top 21 alone. As more NEO migrates and is used to vote for existing nodes for a share of the rewards, this hurdle only becomes higher.

It is good for NeoBurger to implement a smart contract layer enhancement for neo governance.

IMO Approval Voting is a practical way for the enhancement. It is well researched and well verified and widely used in different kind of elections.

For Neo blockchain, the purpose of the election is to elect someone honest more than someone intelligent once the candidate reaches some basic requirements because of the BFT assumptions. That's why approval voting is pretty suitable here.

Fortunately, NeoBurger provides candidates whitelist mechanism and the governance of NeoBurger can discuss the proposals of allowing or disallowing of candidates. Then for users of NeoBurger, they can actually vote for someone outside the top 21 and even vote for multiple candidates. At the same time because of the strategist try to search the optimal strategy restricted by the whitelist, the users of NeoBurger can enjoy best rewards while participate in neo governance.

[vang1ong7ang]

It can be a good feature if NeoBurger can implement it.

[vang1ong7ang]

due to there is no DAO application available currently and it must be costly to implement a DAO and use a DAO on layer 1, i propose to implement the DAO in layer 2.

some main ideas here:

1. time lock is applied to the NeoBurger owner and any one is able to challenge and cancel the operation performed by the NeoBurger owner during the lock time if enough evidence is provided.
2. challengers should be rewarded.
3. the voting platform can be implemented offchain and actually because the voting platform is just only used to prove the existence, consensus may be non necessary.

[doubiliu]

I agree with you. Neo need a Dao. One more a question is whether the implementation of strategies and challenges is complicated, and how can reviewers monitor the normal operation of these logics. Verifiable computing logic, such as tee\zero-knowledge proof or some other effective methods? At least I can get the same result on my local environment if the calculation happens off-chain.

[vang1ong7ang]

@doubiliu let me draft some design and we can review together hope dao can be fun as well as efficient

[lock9]

Hello everyone, I think that the most cast a vote is to actually select multiple candidates. The candidates who have the most votes, would actually be the ones that the application would vote for, and we could only apply that vote, if this is enough to elect that candidate.

Example.

Candidates: A, B, C, D, E

Voter 1 selects: A, B and C Voter 2 selects: B, C and D

This would make the application to vote for B and C, because they had the most votes. If there are more candidates, we would also need more voters, so the amount of elected nodes (by the app) is directly related to the amount of votes we have available.

Here is our algorithm idea. Note that this algorithm tries to optmize the GAS generation and does not include any whitelist. I suppose that we would apply these votes only to our 'elected node list' (some sort of whitelist):

1 - List candidates by votes without counting our own votes

• Loop for each candidate:
  • Perform balanceOf in each sub-contract to find out what was our vote on the candidate
  • Save list of our votes sorted by value
  • Save "voting power" which is the sum of our votes
  • Run getCandidate in Neo's smartcontract to find out the general amount of votes for the candidate (not just the first 21, but all)
  • Subtract from each other to know the number of votes without our interference
  • Save candidate list sorted by value without our interference

2 - Find out which candidates can be elected with our vote

• Loop through each candidate from the bottom to the top:
  • Sum of his votes with our voting power, keep this candidate on a separate list if he can be elected, calculate the number of votes we need to put on him to stay above the safety margin and below the second to last elected
  • Subtract these applied votes from our voting power
  • Continues voting for the remaining candidates using the remaining voting power until exhaustion

3 - Calculate the difference from our current votes to the desired votes for each candidate and do the Splitwise algorithm to make minimal transfers between subcontracts

• Follow the table test below where each column shows the coefficient of how many more votes each candidate has (the negative ones are those that need votes)

.	T0	T1	T2	T3	T4	T5	T6
A	60	10	0	0	0	0	0
B	20	20	20	0	0	0	0
C	10	10	10	10	0	0	0
D	6	6	6	6	6	0	0
E	4	4	4	4	4	4	0
F	-20	-20	-20	-20	-10	-4	0
G	-30	-30	-20	0	0	0	0
H	-50	0	0	0	0	0	0

• It is open what will be the optimization algorithm to perform the minimum amount of transaction, however, a good algorithm can be studied at this link: https://medium.com/@mithunmk93/algorithm-behind-splitwises-debt-simplification-feature-8ac485e97688
• In any case, the number of necessary transactions must be accounted for and if the sum of the costs of these transactions is greater than the expected profit, we will not perform them. The master-contract must send notification of this cost and also a response so that it can be read via testInvoke

4 - Call each sub-contract method to transfer

• Each subcontract will have a method that can only be invoked by master-contract (calling ScriptHash)
• In this method you will perform a transaction, if the same subcontract needs to perform multiple transactions, your method will be called multiple times
• check if it's worth having cached information saved in sub-contracts also in master-contract

[vang1ong7ang]

@lock9 it's very useful idea and i believe it helps a lot.

actually we can split them into 2 questions: 1 and 2 are voting mechanisms; 3 and 4 are strategist operation optimization.

can be inspired by 1 and 2 and we can try to find a practical way

3 is very useful information and 4 has been implemented in the agent contract https://github.com/neoburger/code/blob/main/BurgerAgent.cs

[lock9]

Thanks. So, regarding question 1 - voting mechanism: I think we should allow people to vote on up to "COUNCIL_MEMBERS_COUNT" candidates. If we have 21 today, we should allow users to vote in up to 21 candidates.

About optmization, the best way is to equalize votes on 'the last postion' , something like this:

If we do this correctly, we will maximize the GAS generation for our users and won't influence election results.

Edit: thinking about this, I don't know if this is totally true. I need to recalculate it.

[lock9]

An extra comment: We could, later, have 'public' council / consensus nodes and distribute this GAS to users. We could elect our own nodes, if it is worth it.

[vang1ong7ang]

yes

currently currently NeoBurger consists of a bNEO (main) contract and multiple agent contracts, just like what you post, strategist try to optimize the GAS rewards under the restrictions like whitelisted candidates.

and actually the GAS distribution is fully decentralized and fair and it is already implemented in our smart contract.

[vang1ong7ang]

another kind of choice is to change the election problem to a yes-no problem:

just vote for or against proposals of listing and delisting candidates on the whitelist.

yes-no problems are much easier to implement than elections

then the entire system can be:

• there is a DAO to decide the whitelist of candidates (it can be more than 21 and even more, and of course it can be much less than 21)

• the strategist try to optimize the GAS reward under the restrictions of whitelist (the strategist can be implemented more transparently)

@lock9 do you think it is a practical way at the beginning?

[lock9]

I don't know if it makes sense to have a DAO to whitelist these candidates. Isn't ' being elected' already a task that will need voting / filtering? If someone is able to elect a malicious node, they could also vote to whitelist it, right? Unless we are talking about a 'private' council that will whitelist these nodes.

I'm not sure we need the whitelisting. I think we don't need it (there is some sort of whitelisting on the candidate selection)

Regarding the strategy, I think that there is only one feasible outcome: distribute votes in order to maximize GAS return, and vote for candidates only if they are going to 'win'. We shouldn't allocate votes for those who are already elected. And we shouldn't vote in a node if it won't be elected. In fact, we should vote for nodes outside the whitelist, if these votes don't affect the election outcome. There will be absolutely no difference on governance, but we will make extra GAS 'revenue'.

I think that 'an internal election' (multi selection voting) is important so we know who the app can vote for and change the election outcome. Other nodes could be voted, but only if we don't impact the results (in order to maximize GAS returns)

[lock9]

I think that a very common use case is: "I want to vote for candidate X. But I only want to vote for it, if it is going to win. Otherwise, I'll vote in another candidate that will give me some GAS".

The DApp shouldn't vote for a node if it is not going to win the election, it should only allocate these votes when it is certain that they will be elected.

[doubiliu]

@lock9 I think the whitelist mechanism is still necessary. The reason is that the proxy voting mechanism gives strategists great power, which brings economic benefits and also introduces governance risks. We need to pay attention to this.

There are several possible risk points:

1. Off-chain conspiracy if an algorithm strategy that cannot be verified by multiple parties is adopted, it may cause collusion and cause the operator to obtain improper revenue.
2. Improper strategy, the strategy itself may have some implicit sorting rules or information
3. The influence of the proxy voting mechanism on the overall mainnet consensus, whether there is a low-cost attack method (borrowing, etc.)

..... The whitelist itself may not solve these problems 100%, but this screening system can increase the cost of the attack to a certain extent. The "yes-no" option would be a good way to achieve it. At the same time, we need to introduce some local verification methods (such as the one I mentioned before), which can fight off-chain conspiracy. In addition, do we have a limit on the number of final revised committees,?For example, the number of revisions in neoFs cannot exceed one-third The use of new strategies also requires voting.

[lock9]

Hi @doubiliu , could you please explain a bit more about this 'yes/no' solution? I'm not sure if I get it. I didn't understand this either: In addition, do we have a limit on the number of final revised committees,?For example, the number of revisions in neoFs cannot exceed one-third I'm not very into NeoFS. Is this going to cover NeoFS nodes too?

Regarding the strategy, I think that there is only one: try to elect those nodes we want while maximizing GAS generation. I can't think on any other strategy. What other strategy could we use?

[doubiliu]

another kind of choice is to change the election problem to a yes-no problem:

just vote for or against proposals of listing and delisting candidates on the whitelist.

yes-no problems are much easier to implement than elections

then the entire system can be:

• there is a DAO to decide the whitelist of candidates (it can be more than 21 and even more, and of course it can be much less than 21)
• the strategist try to optimize the GAS reward under the restrictions of whitelist (the strategist can be implemented more transparently)

@lock9 do you think it is a practical way at the beginning?

this is 'yes/no' solution.

[doubiliu]

Fs will limit the count of IR node changes per round, of course, there are some stability considerations. I just put forward an idea, whether we will limit it. A discuss topic, hahha. @lock9

Regarding the strategy, if it is not very complicated and can be executed on the chain, then there may be no problem, but if it involves off-chain calculations, there may be some problems.

[vang1ong7ang]

@lock9 let me change to another version of explaination.

some backgrounds first:

NeoBurger is not native election mechanism and it has no ability to finally decide whom should be elected nodes. stake holders in NeoBurger may have different opinions with other outside NEO holders. NEO governance is to elect honest nodes more than intelligent nodes

so maybe some nodes will be elected in NeoBurger DAO, maybe 5 nodes, maybe 25 nodes, it can be a variable length of elected nodes. but these nodes is not the finally chosen nodes in Neo governance.

I want to vote for candidate X. But I only want to vote for it, if it is going to win. Otherwise, I'll vote in another candidate that will give me some GAS

then strategist will choose some nodes inside the NeoBurger elected nodes, and adjust the vote power between agents and vote to the most earn-able ones.

the next problem is that how to elect such a variable length of elected nodes.

the yes-no proposals is used here. NeoBurger DAO maintain a set of current elected nodes, and anyone can submit a proposal of 'add a new node into the set' or 'remove a existing node from the set'. once the proposal is bypassed, NeoBurger DAO add or remove the node.

why use the yes-no proposal instead of electing nodes directly?

because yes-no problem is the simplest one in group decision making.

actually, we call the set of NeoBurger slected nodes: 'whiltelist'.

[vang1ong7ang]

@doubiliu imo the only aim of the strategy is that to maximize the GAS reward while it better to make it as transparent as possible

[lock9]

I think that this problem doesn't actually exists: the next problem is that how to elect such a variable length of elected nodes.

The reason is that even if we want to elect 10 nodes, we will stilll need the voting power for that. This means that the 'amount' of elected nodes is directly related to our voting power. Also, if the candidate that wins our 'internal election' is already elected, should we still vote for it? I don't think so.

In general, I think that the rule would be:

• From the most voted node, to the least voted node (in our internal election), try to elect it. If we can't elect candidate 1 (or if he is already elected), try to elect candidate 2 and so on. The only 'conflict' scenario I can think of: If we had enough votes to elect our most voted candidate OR elect two other nodes (with less votes). Should we try to elect these two nodes or should we elect only one node?

Also: there will always be spare votes. If we need 1000 votes to elect a candidate, does it make sense to add 2.000 votes for that candidate? We need to know how to handle the spare votes.

EDIT: It seems to me that what we will have is a "ordered list of nodes", we will try to elect nodes based on this list plus gas generation (try to elect those we want while maximizing GAS revenue)

[vang1ong7ang]

@lock9

can you help to explain the pros and cons of the mechanism you proposed and the proposal based election?

imo, most of decentralized application use proposal based voting mechanism because it is really easy to implement. actually snapshot and aragon and gnosis-safe use the same way to make decisions.

[lock9]

Sure. Let me try to explain my thoughts.

What are the 'user demands':

• People want to vote for more than one candidate
• People may want to vote for a candidate but may not be willing to lose money because of it
• People want to generate GAS. It is safe to assume that people want to generate 'as much as they can' (without an increase in risk)
  • It costs to change your vote, and you have to do this manually.

Based on that, my idea is:

• Allow users to vote on multiple candidates
• Allow users to pledge a vote for a candidate, but only enact this vote if this will elect these nodes
• Distribute votes to achieve: maximum GAS generation & elect nodes we want.

How would that work:

• People deposit Neo, we emit a wrapped (divisible or not) version of Neo (like you do here)
• Allow users to vote on multiple candidates. This will create an ordered list of the most voted nodes (internally)
• Make the dApp distribute the votes to our top candidates and maximize GAS revenue. Efficiency is critical here, so we shouldn't vote for nodes already elected, and we shouldn't vote for candidates who won't be elected.

Pros:

• Increased GAS 'revenue.'
• No need to change your votes manually
• More fair elections (I don't have the link here, but selecting a list of candidates is considered a more 'fair' kind of voting than selecting only one)
• Optional pro: Divisible NEO

Cons:

• Increased cost to execute the first vote
• Increased cost to claim GAS

The only thing that I don't know how to handle is between electing more nodes or generating more GAS. Which one should we choose? Maybe we could even have 2 pools: one is pure GAS optimization and the other accounts for vote intentions. In my 'dapp idea', we would allow both, but the second pool would pay a higher 'withdraw fee'.

[vang1ong7ang]

@lock9 actually i think the proposal based election has all the pros you mentioned:

actually the proposal based election is NOT to elect only ONE node, but to elect MULTIPLE nodes.

actually the difference is:

every time we launch a new election to elect a new set of nodes

or

every time we only vote to add one node to or remove one node from the existing elected nodes