Cap P-Reps' ICX delegation share to 2.5% of the total delegated ICX

Governance
,
1

The goal of this post is to start a conversation with the community and P-Reps. It is not a finalized proposal, but I hope that a fully specified IIP will be written following the output of this discussion.

This is not a proposal from the ICON Foundation. All ideas shared below are the result of aggregating fragmented short conversations with the community and P-Reps, as well as our own understanding of the incentives imbalance currently in place in the network.

Special thanks to @BennyOptions_LL for drafting this text and laying down these ideas in clear.

Introduction

Decentralization is one of the main goals of the ICON network. Unfortunately today the network is suffering from a strong vote stagnancy, and voting is a core concept of a DPoS consensus.

This is not a good thing for the network because:

  • It discourages new P-Rep candidates to participate and compete and so the network does not have many nodes securing it
  • While every nodes have very similar costs and produce similar amount of work (specifically, producing/validating blocks and storing a copy of the blockchain), their reward is vastly unequal
  • It concentrates most of the delegated ICX into a few nodes at the top, making some nodes unprofitable while others excessively profitable

Proposed idea

Impose a maximum percentage delegation per P-Rep node of 2.5%. setDelegate function will first check the percentage of votes held by the P-Reps receiving delegation. If the P-Rep is above 2.5% of all delegation, setDelegate will revert.

In English terms, it means that a P-Reps cannot receive additional ICX delegation, if its current delegation represents more than 2.5% of the total delegated ICX on the network.

Goals

More quality nodes

By limiting the max delegation to 2.5%, it redirects newly delegated ICX to look for another node. Therefore, sub and candidates P-Reps will receive more delegation. This encourages more ICONists to run a P-Rep node as it’s easier to compete with top nodes. There would be a minimum of 40 quality nodes securing the network as a result (2.5% * 40 = 100%). It also indirectly encourages ICONists to select their P-Rep in a more attentive manner, rather than choosing the top nodes by default.

Better vote spreading

Delegated ICX will be spread more evenly across different nodes. Therefore it increased decentralization (see the next section for a counter argument).

Fair reward between P-Reps

There is no economic, business or security purpose to having one node earning significantly more money than another node for the same amount of work and expenses. All P-Reps’ costs and work are very similar when it comes to running a node, therefore the reward for doing so should also be similar.

Upon reaching the cap, a P-Rep operator could deploy another node, incurring additional cost to access additional revenue. P-Reps who are looking for additional income could also build products or services on top of the network for this purpose.

It also makes ROI much easier to predict over a long period of time. P-Reps (and those interested in deploying a node) would compare the income generated by reaching the delegation cap to the cost of running the infrastructure.

Potential issues

Service disruption

  • sICX is now a service that delegates to p-rep nodes. This service would need to be adjusted.
  • Wallet UX will have to be updated to provide a smooth voting experience without voting failure.

Sybil incentives

  • Top nodes will deploy multiple nodes in order to continue maximizing their reward, which could become a threat to decentralization if the top 22 P-Reps (main) are controlled by a few entities.

===============

Please share your feedback on this topic.
Thank your for reading.

9 Likes
2

This is an interesting proposal, thanks for putting it up for discussion.

I’m not opposed to the idea, and do think it could help decentralize the network further. The part I don’t quite understand yet is to how to trigger votes to decentralize in the first place. For example, Binance has 52M votes right now.

Even if the 2.5% is activated, what’s the mechanism that would encourage those votes to decentralize to other nodes? Binance has a single wallet with 50,000,000 ICX of voting power. Does the proposal have any incentive mechanism that would encourage them to spread that across different teams?

3

There would most likely two things happening

  • Top nodes will not receive any new delegation. there won’t be any reset or reduction in terms of delegation
  • Top nodes will register multiple P-Reps and max them out at 2.5%
4

I think this creates a vulnerability and wouldn’t work.

Top teams like Binance will not voluntarily shut down/reset their vote total. By limiting how much new teams can gain it hampers decentralisation, no? The idea is great if we were voting fresh.

The spirit of this idea is to decentralise network funding further, maybe IISS 3.1 could have a different rewards structure to achieve this goal? Rewards could be capped at 2.5% of votes. Everything over that could be then auto split amongst all live validators as a block production reward. Ie incentive sub node operations further.

This would force large exchanges with cold wallets to run multiple nodes. Due to 1 coin being 1 vote in DPos it doesn’t change governance influence if an entity has multiple nodes?

Thoughts?

5

I believe this approach has already been discussed in the past and why it wouldn’t work. Binance will create 5-10 new nodes then use their 52M votes to take up 5-10 extra governance spots. Bad idea.

6

Yes. Maybe this could be coupled with an increase of the number of main P-Rep, or we could set the cap to a higher value at first and decrease it over time according the amount of ICX top nodes already controls (even though that’s not easy to really know in reality).

1 Like
7

As the one come up with this idea you can solve this issue with vote weight. You put some threshold where rearward + governance weight drop over that number let’s say 1% deploying 5-10 nodes are not feasible
under most circumstances double this number just doesn’t make sense. Even at current state with all reward drops and bond. I don’t think it’s feasible to deploy that many nodes while staking is much more simple and easy to manage.

8

I like the idea in general despite some complications for the initial transition from the current model.
I’m not a P-rep so I don’t know this information. If we cap to 2.5%, and we go into a bear market and price of ICX drops to say $1 or lower. Will that 2.5% be enough for a decent quality server and backup for the P-rep node?

9

Mineable’s point was that you can just register as many P-Rep as you want when you hold large amount of ICX. There is nothing we can do at the protocol level to defend against sibyl.
You can only defend against this through centralized control (for example KYC), which is an unacceptable alternative of course.

Today, Binance could already register 7 nodes and all of them would be in the top 22 (sum of last 7 main P-Reps delegation is ~47.8M ICX, Binance has ~52M ICX). With a bit of help (they would need one more node) they could block every network proposals. But they don’t do that because they have no interest in the network, they are ROI driven.

Maybe the issue is not about the number of nodes controlled by the same entity, maybe the issue is that only the top 22 P-Reps can actually do governance, and this is a limiting factor in what we can do with delegation settings?

2 Likes
10

I think one effect of this 2.5% cap is that it pushes ROI driven P-Reps out of the system (they will re-allocate their capital somewhere else with better returns) and leave some space for “principle driven” P-Reps.

So by “quality” P-Rep I mean P-Rep would actually work on improving the network, do governance, make proposals, code core tech, between other things. Which I think is healthy.

Also remember that P-Reps manage network inflation. If price tanks and most of them can’t keep up, they can also adjust it.

11

Gotcha. Yeah, all great points.

12

I like the thinking behind this initiative. However I dont think regular voters should be penalized with the sytem that is removing their votes and staking rewards when they are delegated to the oversubscribed validator. Vote stagnancy has been a common problem from the start. In order to stimulate voters I prefer to put in place positive economic measures rather than restrictive ones. There are and there will always be passive stakers that dont check their stake/vote very often and we should not bash them for that.

I am in favor of approach mentioned by @NorskKiwi to cap the max reward per validator, so that oversubscribed validators would not kick passive voters but instead provide reduced staking rewards… In the example I will be using a fixed amount as it is easier and more stable rather than using dynamic limit with the % involved.

Lets say we cap the max reward per validator at 12.5m ICX. That is around 2.7% from total staked amount of ICX ~450m. So that means that all the PReps with the votes below the 12.5m ICX threshold will provide the nominal annual APY to their voters which is around ~9.75% at the moment.

The oversubscribed validator annual reward is capped at 9.75% of the 12.5m ICX which is 1.21m ICX of rewards per year. In the optimal condition this 1.21m ICX rewards would be distributed equally between the 12.5m ICX votes.

However, if the validator gets oversubscribed with the 25m ICX votes, reward stays capped at 1.21m ICX per year. This time this reward is distrubuted equally among much higher amount of votes. This distribution would reduce voter staking APY from 9.75% to 4.875%. I believe this will provide enough economic incentive for the voters to look after the validators that provide most optimal ROI. On the other side passive ones would still continue to earn staking rewards at the reduced rate.

Big exchange validators like Binance are reality in most of POS derivative systems and as it mentioned before they are mostly ROI driven which means they are almost always limited to use only their own stake on their validators. In case mention above extra votes would only reduce their ROI so incentive to attract additional votes is not there.

The reality that big entity will run multiple nodes can happen anytime even right now. And instead of constantly worrying about it, we should just let it happen. In this example Binance can easily place 4 nodes and be at the 12.5m ICX cap. Same as for the other entities. More servers - more work - bigger cost.

On a short term this could affect the governance process which can easily be adjusted by increasing the voting rights to higher amount of p-reps (30-40?). On the long term, voters or services (Balanced, Omm) will look after the best and most stable ROI. In practical terms this means that votes will not likely go to the ones that are over the limit or close to the limit. Votes will be better spread around and more decentralized. Ideally over the long period of time we should see smaller differences between the votes where we should get more nodes grouped around 10m votes.

Just a thought.

13

@bwhli - it works at the time of the setDelegate transaction. Ad mentioned by @nym, setDelegate transactions that include a node that is above the cap will revert. So, let’s say Binance tries to stake again with that 50,000,000 wallet. They would no longer be able to do so. All their transactions fail until they setDelegate to a team without so much delegation.

Please see above explanation to Brian’s question about how nodes are forced to reset. If Binance ever wanted to remove any votes, increase or decrease delegation from that wallet, they would need to spread the votes around or the transaction would fail. Essentially, that entire wallet becomes locked until it sends a setDelegate transaction to a node that is below the cap.

This is not the case. Voters are not effected. This is how it works:

To explain further, let’s do an example.

  • bobNode as 5% of delegation
  • Alice is currently delegated to bobNode
  • Alice still receives i-score and rewards as normal
  • Alice claims i-score, no issue, and receives 5 ICX
  • Alice stakes the additional 5 ICX
  • Alice tries to vote an additional 5 ICX to bobNode
  • Alice’s transaction fails (reverts)
  • Alice says “I can’t seem to vote for bobNode, let me try somebody else”
  • Alice tries to vote for charlyNode with the new 5 ICX, but keeps all other votes on bobNode
  • Alice’s transaction fails (reverts)
  • Alice sends a transaction to remove all votes from bobNode and it is successful
  • Alice sends a transaction to vote all of her staked ICX to charlyNode, who is well below the cap, and it’s successful

Now, I walked through all of that so you understand how it works, but of course, the user interface would prevent all of these failed transactions and tell Alice, right up front, why her transaction would fail if she tried. Hence the earlier point by @nym that I’ve quoted below:

This is also an interesting idea that I had discussed with @nym prior to this post. It accomplishes an almost identical goal, but with considerably more development time and resources. The current proposal would be a small adjustment to our existing structure. Complexity, dev resources, likelihood of bugs, etc. should always be a major consideration for network upgrades.

It also doesn’t accomplish a fixed minimum number of nodes on the network, but this is less of the point. I like the idea, don’t get me wrong, but I don’t see the marginal benefit when it would have the same result, but take a lot more frontend, backend and core blockchain work than the delegation cap. It essentially just provides a gradual push to the same result.

100% agree here. There is nothing intrinsically wrong with one entity running multiple nodes, so long as we grow the main p-rep set over time imo. The only realistic issue is if somebody had enough ICX that it was economically beneficial to take up more than 1/3 of the governance slots.

2 Likes
14

I’m interested to see a dpos model where all delegation is put into a pool and this pool evenly spreads out votes across all nodes depending on the node operators collateral as a % of the entire collateral of all the nodes.
What this does essentially is, make Node operators fight to lock in the most collateral, whilst at the same time, creating a level playing field to earn votes.

15

Yeah I generally like the idea and approach but I do think we need to consider increasing the number of “main p-reps” in some way, almost as a requirement for this to happen. Ultimately we can’t stop big players from spinning up multiple nodes, but at least this way if they want to capitalize on that, there needs to be much more effort and resources put forth to mange it.

2 Likes
16

This is then NOT solving the problem. Sorry but it’s true. You can’t just say the current votes will remain the same but the current preps will just have their rewards capped. This does not solve the issue at all because 90% of the stagnant votes are on the foundation and others near the top. This does not help spread votes and it just reduces the rewards to preps who are actually doing work.

We need to stop trying to make 100 changes to the way things work at the same time. This is how things blow up in our faces. Let IISS 3.1 come out with bond requirements and let’s see how the network is at that time. IISS 3.1 is almost literally the same thing as what you described where votes over a certain amount on a prep won’t count for rewards except it’s based on how much bond they put up and not some random arbitrary number. The more a prep can stake for their bond the more they SHOULD be rewarded imo. This is what decentralized means, not a centralized control of some max cap % on votes/rewards.

2 Likes
17

I think one effect of this 2.5% cap is that it pushes ROI driven P-Reps out of the system (they will re-allocate their capital somewhere else with better returns) and leave some space for “principle driven” P-Reps.

So by “quality” P-Rep I mean P-Rep would actually work on improving the network, do governance, make proposals, code core tech, between other things. Which I think is healthy.

At 2.5% you are talking about a cap at around 8mil votes, there’s only 12 Preps with more than 8mil and out of those 12 preps only 2 do not do anything for the network. So where are these ROI chasing preps you are talking about? Prep inflation is such a small issue now that it’s already been severely reduced from previous network proposals. The biggest source of inflation is staking ROI. Honestly we need to look at reducing the staking ROI and forcing users to earn the APY by actually USING ICON dapps and not just staking their funds. They can easily help secure the network by supplying collateral to dapps rather than just staking and doing nothing with their ICX.

2 Likes
18

Seems to me everyone keeps trying to do more to “help” the preps make less. I am personally more interested in seeing our transaction fee adjusted, and to lower the massive voter rewards that have not been addressed. We should not encourage a system that encourages some entity to spin up 10 nodes to increase their income through running mulitple nodes. I think the bond will be difficult for some nodes to come up with alone, and will be skin in the game enough for now. We need a decentralized solution and not a centralized solution to the vote stagnancy issue which has been around since inception. Honestly most normies have a hard time just learning what staking is and how to vote with their wallets, much less become and stay involved.

19

100% agree here. There is nothing intrinsically wrong with one entity running multiple nodes, so long as we grow the main p-rep set over time imo. The only realistic issue is if somebody had enough ICX that it was economically beneficial to take up more than 1/3 of the governance slots.

Yes there is. I totally disagree especially if they could be malign actors and part of the CPS voting against things they don’t “agree with”. At least in the short to mid term.

Slippery slope sir. Slippery.

20

Nobody is trying to make 100 changes at the same time, hyperbolic statements are not needed. @nym is trying to get the community more involved in discussing the future of the network from an earlier stage, rather than ICON working on something for a long time then simply proposing it. It would be great if we could have a level-headed conversation about the future of the network, logically break down pros and cons (as @nym did), and proceed at a reasonable pace.

All - Thanks for the feedback on this proposal. Everybody should feel free to make proposals and start discussions of their own as well. Stagnancy (not vote stagnancy, but development stagnancy) is an issue with many blockchains. As mentioned above, this proposal was meant to stimulate discussion as we prepare for the next stage of growth and enhancements to the ICON Network. It’s meant to create a more decentralized governance process by getting everybody involved earlier.

3 Likes