[Governance] Design and discussion #1617
Comments
|
Hi @SueNEO, It looks good. I did not see any mention of Staking. We need to discuss if Committee (or CN, all the same in terms of registering on the Blockchain) will pay GAS or stake NEO during the period they want to participate. |
I thought about it and found it difficult to calculate. Because when I claim GAS, the object I vote for may switch between the consensus node and the committee member. How do I calculate what percentage of GAS should I get? If the GAS distribution is forced on all accounts when the role changes, the calculation will become very large. |
|
More seriously, when the balance of voters changes, the GAS distribution will also be affected. |
|
Good to see a proposal like this! Nice work! 🎉 So... I just put my questions and thoughts in some bullets points, below. While some are things that are not so clear to me, others are things to raise awareness and, maybe, start brainstorming. :-)
|
Yes, it's a continuous process. But I think we may need to adjust it or adjust the GAS distribution, as the calculation problem.
I think that "incentive to actually use the Neo blockchain network", it's a off-chain mechanism. As NEO is the governance token, we should incentive the holders. |
|
I think we can use the concept of epoch, like one epoch equals 5760 blocks(1 day), and we'll make a snapshot of the voting record(snapshot format: User can only claim the previous epochs' GAS, and when the balance of voters changed or switch the votee, both will automatically trigger the claim operation. |
|
You mean who voted, regardless of who? |
I think so. |
I think committees can decide it, this is their responsibility. Maybe we can use it as the default value? |
|
It's a good suggestion to let more nodes play value, this is related to consensus mechanism and economic model, like dBFT3.0 proposed by @igormcoelho and @vncoelho , has similar ideas. And I think we need more time for thinking the next neo consensus mechanism. |
|
I think it is a good time to consider letting any node propose blocks. It seems to me that we don't really require the CNs to do any more work other than validate as a group, they are the root of trust. But processing of transactions, we could shift that workload to other P2P nodes on the network who in turn can receive the total network fee for the block. Mining but without the waste. This opens up the opportunity for the network to incentivize participation from all nodes, helps decentralization, and can become a very useful tool for businesses on the network wanting to streamline their services to end users. They could batch their own transfers as new blocks, as long as the numbers add up it is no different in the end than a block of completely random tx proposed by a CN. One important thing here is that I think it answers the question of "why am I using Neo?" Like with chains driven by mining, it is worthwhile to use the network if the return fee is sufficient. If you can use Neo's facilities to generate profitable transactions, then you have reason to use it and you can specify your own fees for users (as long as it passes the minimum as set by the committee). Regarding GAS calculation... one option is to use an equal fee for all top 21 nodes, i.e the committee, regardless of whether or not they are actively the top 7 performing consensus. They are held to the same standard, are expected to provide the same service, so should earn the same share. If we reward the Top 7 separately, we risk incentivizing NEO holders to concentrate their votes into the candidates that already have the most influence, meaning we will trend towards plutocracy as has been demonstrated in practice in existing dPoS models including Lisk, Tron, and EOS. |
|
Agreed with Edge. As I mentioned on Reddit, I am a little worried that voters will end up always voting the 7 previously proven winners of previous voting rounds, in an effort to maximalize GAS rewards. If you vote for a CN candidate that was previously not CN, your chances of getting less GAS significantly increase (unless others also do it). Best to distribute the additional GAS rewards to all people who vote, and NOT just to all people who vote correctly. Also more easy to implement this way, I guess. |
The problem is vote once, means vote forever. Is there any big difference with neo holders? |
It dosen't mean, vote for CN will get more GAS than vote for CN candidate. Actually, the reward tends to be in dynamic balance. As the following:
|
|
@EdgeDLT,it is good that you are pushing this discussion, we need to discuss that and align with what NeoResearch team has been investigating for dBFT 3.0, @vang1ong7ang is also aware and perhaps some members of the community since we already made the report available,as well as the first mathematical model. In the report we propose the redudant primary in order to allow other nodes to participate. |
|
@EdgeDLT makes a great point. More incentives to participate in the network would be great. Like with ETH2, users are incentivised to run node validators because they can earn passive income of the networks native token if they are chosen to propose a block (& also for confirming blocks, but that wouldn't be the case for NEO). However careful consideration needs to be taken into how it would affect the performance of the network. One of NEO 3.0s strong points would be its performance. |
|
An idea: Perhaps there's value in having a finite lifespan for votes. The logic for this is as follows. As seen in DPoS systems, financial incentive is a great way to get people to vote in the first place. However, a separate question is how to KEEP voter engagement over time and ensure that elected nodes reflect current, not past, performance. It's common for voters to vote for a relatively safe candidate with little chance of falling out of the committee (or its equivalent), and then stop paying attention to governance issues. This 'voter inertia' results in a static committee, which results in less incentive for other nodes to try to join the committee, which, finally, results in a reduced incentive for nodes already in the committee to continue improving their offerings. Ideally, a governance system should not only incentivize voter participation, but also include a mechanism to ensure ongoing competition among nodes. As I understand it (correct me if I'm wrong) NEO nodes are all equal in the reward they can return to voters. That means that the choice of who to vote for should come down to which nodes offer the best service to the network. However, in a system where 'voter inertia' causes nodes to remain in the committee based on past, not current, performance, in practice it may be preferable for a new voter to vote for an entrenched candidate even if there are better alternatives for the network, Having votes expire after a set period would incentivize voters to continuously (or at least periodically) engage with the governance process and reevaluate their votes. On the opposite side of that same coin, it would encourage nodes to compete for votes. There's no way to guarantee that voters would carefully assess the candidates, and, as in real-world democracies, there would probably always be a bias toward the incumbents. But by reducing the incentive to vote for an established incumbent purely for personal gain, vote expiration would make it easier for more voters to choose based on the only differentiating factor that remains: value to the network. It's also relatively simple to implement. In terms of specifics, there'd be plenty to discuss. How long should a vote last? Should the timer be relative to each vote, or should there be a set 'election day' every so often, on which all votes expire? Anyway, just an idea. Cheers. |
@Elean0rZ As the voting weight may adjust the reward.
|
|
After initialization, which are the mechanisms that are going to be used for updating |
I think it can't be updated by committees, as these related to protocol settings, like dBFT2.0 may have the max limit for consensus nodes, and dBFT3.0 may support more validators, and this can't be decided by committees but L1 protocol. |
|
Great discussion! I have summarized the discussions of #1617 and #1446. The following are the questions that have been raised and may need further discussion:
|
|
@grace-gui Thanks for summarizing! For me..:
100% yes. I'd go one further and say that all candidates should run a node, demonstrating that they are capable of securely operating a node before being entrusted with joining or otherwise influencing consensus (and it doesn't hurt to show willingness to help the network out of pocket). This also allows us to use node health metrics as a way to assess candidates, which can help inform NEO voters who may otherwise struggle to make educated decisions. It also gives us the option to later have committee members contributing in other ways, like running an oracle service or being hot-swapped into consensus if a CN is byzantine.
I am not sure on this point. I like the idea of having no barrier to entry and letting the NEO holders call the shots on who moves up, but stake means skin in the game. I think a stake to be a candidate is probably for the best, as long as it is not so high that it is unnecessarily prohibitive.
There should probably be a cycle. People signing up for that responsibility should have a base estimate of how long they are expected to participate. Maybe every 3 months?
Following @Elean0rZ's comments, I think this is a good idea as long as it is not so short that people need to constantly re-vote. Every week seems too frequent, so maybe a 1 month expiry (or until the end of the election cycle if it was a late vote) would be viable?
Veto power on a proposal for CNs as proposed should help solve this problem, since they have the most votes and can prevent a malicious decision from being enforced. It's not a guarantee, but it helps if we require candidates to state their preferences up-front where possible. This gives us something to compare against the final proposal. E.g, if 2/3 of the committee wants higher fees (and are voted in on this point) but the final proposal would reduce them, we can tell something is wrong.
What duties do they have specifically, and what does it mean to not perform them? Is abstaining from a vote not performing a duty, for e.g? What about extenuating circumstances? Do we punish by slashing the candidate's stake, or withholding what would be their share of the committee rewards? This one is a big rabbit hole heh.
I would like to see further exploration into incentives for non-CNs. Not sure what is exactly meant by usage of the network, general usage should all be paid for. If you mean things like a community fund for issuing grants to projects, then I guess it's something that could be explored, but in today's climate this is solved by crowdfunding and private investment so there's no rush IMO. |
|
@Tommo-L, the commit 9cbc025 of @erikzhang solved this issue now I think. Now the protocol defines the maximum and the voting process defines the order, correct? |
|
It looks like that, but I can't find the related PR. |
|
It was directly committed, @Tommo-L. It would had been better if a PR was opened for us to clear this topic, @erikzhang. |
|
The approach of rewarding voters who I'm very concerned that it will have a passivating result where the community will simply fall back on the "safe vote" instead of the "right vote". Having experienced this firsthand in the US...Many people simply vote for a candidate because they "think" the individual will win in lieu of a personal preference of who is the most qualified candidate. I do not think this mentality is in the best interest of the ecosystem and it will happen naturally whether we add an incentive or not so we shouldn't go further to motivate users. It also further motivates brigade voting and centralization. For example: if a Binance-like actor were to announce who they are voting for, this model would be providing a financial motivation for other voters to also vote for the same entity so the network is effectively rewarding users to centralize. We will already have enough issues with people |
I think the fundamental rationale behind the aggregation of votes towards the final winners is to incentivize active participation and to provide security and stability to the consensus process. Imagine the scenario that any voter will be rewarded, there are some associated potential problems:
Regarding the "Binance-like" actors, I think this is an very important issue. When we introduce a certain level of imbalanced distribution of rewards to the system instead of a universal passive reward, institutions will participate to reap the financial benefits. I think the same things will happen to any POS style blockchains, it is an inherent problem of introducing staking, a large proportion of any token holders are speculators. Looking at this issue from a more positive perspective:
However, there should definitely be more discussion on how to limit the impact of those actors, considering that giving the initial distribution scheme, if the vote rate at the beginning is not very high, the financial return of those voters will be very attractive. |
Maybe I'm misunderstanding, but it seems to me that this would only be true at the very start, and that after that, this system would actually discourage active participation. Consider:
The result would be a system in which, over time, the committee becomes more and more entrenched. Even if other candidate nodes provide amazing services, the financial incentive would still be for voters to support the committee. In effect, it becomes a tacit agreement among voters: We'll all only vote for these 21 nodes, so everyone 'wins'. Well, everyone except the network, since there's no incentive for nodes to compete and improve. Over time, this means that committee nodes can become 'lazy' regarding the services they provide. Meanwhile, non-committee nodes would slowly be discouraged from even trying to offer superior services, since their efforts would rarely be rewarded with votes. And voters would 'set it and forget it', knowing that there was no reason for them to remain actively involved in a process that isn't really a 'process' so much as a completed decision.
Sure, but then what is the point in having voting at all? If all incentives encourage aggregation of votes around the committee, then the result is, in effect, the same as if we just say "OK everyone, there are 21 permanent nodes". The whole point of having a voting system is to allow for turnover and renewal of nodes, to discourage laziness within the committee and to encourage innovation and effort on the part of non-committee candidate odes. You can argue that vote aggregation makes it relatively harder for bad actors to 'swoop in', but the flip side is that they can still swoop in right at the beginning, and if they do, they are much harder to remove, since there's a financial incentive for voters to continue voting for them (i.e., network interests and voter interests aren't aligned).
Yes, but that is the whole point of voting. There needs to be a realistic possibility of changes in consensus nodes in order for committee members to be motivated to maintain a high quality of service, for candidate nodes to be motivated to try and offer something better, and for voters to be motivated to take an active role in choosing who they think will benefit the network the most. This renewal and refreshment and ongoing 'incentive to be better' is vital to keeping the governance system up-to-date and efficient. Turnover might increase the possibility of errors in the moment of transition, but a lack of turnover would reduce the overall quality of committee nodes and increase the possibility of errors during normal operation (e.g., less incentive to continuously upgrade one's server or uptime, say). There's no doubt that having a static 21 committee nodes would be an efficient system, and this is certainly a strength of permissioned chains, but again, if that's the desired outcome here then why bother having voting at all? If we want to incentivize voters to actively participate, we need to ensure that votes mean something, which means that there has to be a realistic possibility of turnover. However, as I've proposed before, another approach is to make votes expire after a period of time, so that voters need to remain engaged if they want to maximize their rewards. Combining the current 'vote aggregation' approach with a vote expiry system might be a way to balance all interests here. |
Governance
There are three types of roles in the system:
Token and incentive model
Neo has two native tokens, NEO and GAS.
NEO, with a total of 100 million tokens, represents the right to manage the network. Management rights include voting for consensus nodes and the committee, and so on.
GAS is the fuel token with no upper limit, which is used to control resources when using NEO network. Each block will issue additional GAS in order to incentivize NEO holders and users who contribute to the system, making the system sustainable autonomy. The additional issuance of each block can be adjusted by the committee. Initially, each block issues 5 GAS, that is, about 10 million GAS are released each year.
The additional GAS allocation is as follows:
10% is estimated according to the charging mechanism of NEO3.0, so that 10 days after holding 10 NEO, one can get the GAS needed to send a transaction. This design guarantees the convenient use of NEO holder without falling into the dilemma of having to go to the exchange to buy GAS. 5% is estimated based on the cost required to maintain the committee node, which could cover the cost of the committee node. Under the increase rate of 5 GAS per block, the average GAS income of NEO holder is calculated as follows (the red value in the table is the annualized returns based on the NEO / GAS price of 7: 1).
The extremely high income deviation will encourage NEO holders to actively participate in voting, and will not vote blindly, but vote for the node that is most likely to become a consensus node, this will make the voting more concentrated and not too scattered.
Transaction fees are divided into system fees and network fees. The network fee is allocated to the current speaker (the consensus node that proposed the block) as incentive, and the system fee will be burned.
The text was updated successfully, but these errors were encountered: