Building Governance Enhancement in Smart Contract Layer

[dusmart]

As @edgedlt said in neo-project/neo#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?