[Governance] Governance

[SueNEO]

Governance layer is the layer to choose the dynamic parameters of consensus layer in a decentralized way.

There should be some dynamic variables, such as number of consensus nodes and addresses of consensus nodes, cannot be hardcoded in the consensus layer. Then the participants of Neo should specify such parameters to make Neo running well. That's the way we call it on-chain governance.

Governance Abstraction

The governance layer here only focuses on the on-chain behavior.

Of course, many organizations, including Neo Foundation, can make their own excellent governance policies or interim policies for better development of Neo. But such policies are all off-chain governance.

Since governance layer is the on-chain mechanism, the input of governance process is a sequence of transactions. All the governance behavior can be performed by sending a governance transaction. Since neo has the great feature of one block finality, deterministic governance can be much easier deployed. As a result, the output of governance process is the key parameters of consensus layer.

Governance Metrics

The following metrics can be used to evaluate the solution of governance layer to know which solution is better. It is better to choose a solution with higher pareto efficiency and lower cost.

1. pareto efficiency
2. cost of computing, storage and network resources

Governance Solution

The solution will be proposed in the following sections. It may be not optimal because we are facing trade-offs among all the performance metrics of governance layer.

Principles of Governance

The principle of governance will be introduced first. The following principles are well accepted by most people.

1. On-chain governance is cyclical.

   Governance on Neo will never stop unless Neo stops. We separate it into cycles to make it easier to design and describe.

2. There may be overlaps between cycles.

   For flexible network and we don't want the network hang.

3. Neo use voting mechanism to make group decision.

   It is the only way to make reasonable group decision we have ever seen.

4. 1 NEO, 1 vote.

   It is the best way to match the interests of Neo and the voting weight of Neo and it is the necessary way to avoid strategic voting and ballot spliting or merging.

Governance Cycle

We seperate the governance processes into infinite cycles. A governance cycle consists of two parts:

1. decision making phase (DM)

   voting based group decision making phase for key parameters of consensus layer

2. policy deployment phase (PD)

   deployment phase of the voting result, for example, the elected consensus nodes start the consensus with the parameters selected in the decision making phase

Time relationships of them are shown in the table below. The first column is the round of governance cycle and the rest of columns are the time of each cycle. As the table shown, the policy deployment phase of the previous round and the decision making phase of the next round are at the same time.

RoGC	...	n-2	n-1	n	n+1	...
n-1		DM	PD
n			DM	PD
n+1				DM	PD

RoGC: round of governance cycle; DM: decision making phase; PD: policy deployment phase;

Cycle Length

The cycle length is fixed 180 days, which means, the first 90 days of a governance cycle is decision making phase and the later 90 days of a governance cycle is policy deployment phase. Then, as a result, the tenure of consensus nodes is 90 days.

Currently we choose fixed 180 days as cycle length because the voting rate in Neo2 is pretty low and we recommend to gradually introduce NEO holders to participate in on-chain governance of Neo. Actually it is a trade-off between pareto efficiency and cost because NEO holders need to spend time, energy and even money in participating the governance process. We don't want to introduce too much cost to governance process at first, so we choose 180 days as the governance cycle length, which means, NEO holders need to vote for their choice about 4 times per year. Optional optimization of dynamic governance cycle length is proposed in #1439.

Voting

Governance layer is for choosing the dynamic key parameters in the consensus layer in our definition. It is the responsibility of consensus layer to provide what are the key parameters and what are the valid values for each parameter. In other words, the range (content, topic) of governance layer is decided by the consensus layer.

On decision making phase, every NEO holder can vote for its choice. Voting is public and visible on the blockchain. Delegated voting is allowed.

Considering the cost and complexity, we choose public and visible voting because it is simple although it may not friendly to privacy of voters and cannot avoid some kinds of strategic voting. On other hand, if voting is not public nor visible, there may be still similar problems.

Token Lock

We allow those NEO holders to deposit and lock their native tokens into a special native contract. The voting weight is directly proportional to the number of locked NEO. NEO is locked instantly until the end of policy deployment phase of current governance cycle if the NEO holder participate in governance process of current governance cycle (voting). Otherwise the NEO can be withdrawn.

Actually there are overlaps between governance cycles. NEO holder can use the locked NEO to vote in next governance cycle when the decision making phase of next governance cycle comes, but those NEO cannot be withdrawn.

Token lock is necessary to protect Neo. It can avoid double vote and, more importantly, let the voters take their responsibility. Imagine if some one can vote and then sell the NEO to another one, the one won't bear the loss of the price drop of NEO. As a result rational NEO holders will not vote responsibly and even vote for byzantine consensus nodes and then do shorts on NEO to earn more money.

Counting Algorithms

Key parameters of consensus layer such as number of consensus nodes and consensus nodes list will be select via the voting mechanism of Neo governance process.

Different counting algorithms are used for different kinds of parameters.

1. for scalar quantity

   A scalar or scalar quantity is a quantity that can be described by a single element of a number field such as a real number or an integer. For example, number of consensus nodes is a scalar quantity.

   we choose median of all the votes as the result.

   According to the median voter theorem, a majority rule voting system will select the outcome most preferred by the median voter. Choosing the median as the result means that at least 50% voters agree that the value of parameter should be greater than or equal to the result and at least 50% voters agree that the value of parameter should be less than or equal to the result. In addition, median can be found by sorting algorithms with O(n log n) time or optimized median finding algorithm with O(n) time.

2. for enumerate quantity

   enumerate quantity means discrete enumerable items. For example the addresses of consensus nodes are enumerate quantities.

   We recommend to use combined approval voting (CAV) to select the enumerate quantity.

   Vote splitting is an electoral effect in which the distribution of votes among multiple similar candidates reduces the chance of winning for any of the similar candidates, and increases the chance of winning for a dissimilar candidate.

   A well-known effect of vote splitting is the spoiler effect, in which a popular candidate loses an election by a small margin because a less-popular similar candidate attracts votes away from the popular candidate, allowing a dissimilar candidate to win. As a result, the notion of vote splitting is controversial because it can discourage third party candidates. Strategic nomination takes advantage of vote splitting to defeat a popular candidate by supporting another similar candidate. Vote splitting is one possible cause for an electoral system failing the independence of clones or independence of irrelevant alternatives fairness criteria.

   Cardinal voting methods are immune to vote splitting, since each candidate is rated independently of each other.

[vncoelho]

Very good description, @SueNEO.

I agree with most of these, @vang1ong7ang had already explained some of these concepts during his journey here in Brazil.

In particular, I support these Token Lock and the cycles.

About the Pareto Efficiency, do you want to draw any set of non-dominated solutions or that is more like an explanation about the complexity and the need of multi-criteria decision making?

[vang1ong7ang]

@vncoelho

Let me explain it.

Pareto Efficiency is to measure the quality of voting result. Different voting algorithms provide different voting results. Some of them are better while some not.

Actually pareto efficiency is one of the metrics for us to compare different voting solution and choose the best one for us.

We give 2 examples for that.

One is for scalar value (i.e. number of consensus nodes): we believe median is always the best voting result (which achieves maximum pareto efficiency) which is different from neo2.

Choosing the median as the result means that at least 50% voters agree that the value of parameter should be greater than or equal to the result and at least 50% voters agree that the value of parameter should be less than or equal to the result.

The other one is for enumerate value (i.e. the addresses of consensus nodes): combined approval voting is used here because it is a trade off between pareto efficiency and voting cost. Combined approval voting is pretty similar to the way we used in neo2 but a bit optimized to avoid vote split.

[vncoelho]

Thanks, @SueNEO, I understood the Pareto, in fact, I have some works in Pareto Efficiency for Multi-Objective Optimization.

Where do you plan to use it, on real-time?

[vang1ong7ang]

@vncoelho

We use it only when we compare different governance mechanisms. I think it is not on 'real-time'. It is only on 'designing-time'. It is only used for us to choose the final governance mechanism,

[JustinR1]

Just a community member here,

Definitely in favor of locking tokens in a native smart contract when voting for consensus nodes. I really couldn’t see it any other way honestly.

I also think that a speaker should sit out a round to allow others the chance to be voted for. They can still be delegates though. Just a thought.

[belane]

If the proposed cycle is 180 days (or dynamically chosen), what would be the way to force the replacement of an elected member?

[vang1ong7ang]

@belane , honestly we did not design a way to force the replacement of an elected member. Actually we give ac promise of fixed term of office to the elected member.

But you mentioned a good idea, which can be introduced in the governance mechanism, as a optimization or enhancement.