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

Governance
,
#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
#21

thanks for posting this and opening up the conversation, just finished reading it and wanted to make a quick comment about the “sybil attack” sorry if someone already mentioned this, I havent read all the replies yet.

If this is approved the “sybil attack” scenario could be avoided if we expand the block producers to more than 22 top nodes (maybe top 50?) but if my understanding of PBFT is correct if we increase the amount of block producing nodes this will make consensus slower and the block generation will be slower, maybe this is not the case for us since we use LFT2 but I dont know enough about the details of how consensus is achieved to be completely sure

the other important point is that if we increase the amount of block producing nodes it will have an economical impact on the operators that will need to be analyzed and/or discussed too

1 Like
#22

I agree with Geo on this, the best action right now is to wait for the bond to be activated and see how many nodes are able to successfully post their entire bond, after a couple of month we can evaluate and act accordingly.

is highly likely that the bond will improve this situation

2 Likes
#23

Agreed.

Nym’s proposal seems like the most efficient solution to asymmetric vote distribution, which I do think is a problem. It’s important to spread resources and increase number of main p-reps in order to maintain a meritocracy and increase decentralization.

The multiple node issue seems like an inevitability that can only be stopped by expanding the number of main p-reps.

I’m still new to all this but is it possible to just redistribute the voting rewards of those over the proposed 2.5% equally to the rest of the nodes? If not and the solution is voters being prompted to vote for an alternative P-Rep then I think it is important to have vote guide functionality built into the wallets. These should display the P-Rep’s action plans, bios and milestone updates.

I also think we should consider have voting refreshment period where every six months or so you should be prompted to review your vote distribution. This encourages more thoughtful voting than the default which for many is just set it and forget it.

#24

There’s changes already pending to be made to the governance contract and we are discussing more changes? This is what I’m talking about. Give the current changes time to take effect before we can even consider more changes. How can you even know what will need to be changed after 3.1 if 3.1 isn’t even live yet?

3 Likes
#25

I agree with Geo. Let’s start by implementing bond requirements as discussed earlier. Perhaps that alone will be enough to fix the issue? Give it some time. If we start throwing the whole kitchen sink at once, we’ll have no idea what’s actually working.

Furthermore, I’m still not seeing a satisfactory solution against large entities spinning up multiple nodes and potentially taking over the ICON network. So as it currently stands Mineable would vote to reject this proposal.

#26

Hello (decentralised) CPS?

#27

First, I think we need to consider “Decentralization”! I don’t really understand how ICON came up with only 22 Main P-Reps who can produce blocks?!? I don’t think 22 can be considered a decentralised network at all! If ICON is worried that more Main P-Reps producing blocks can bring security risk or some other form of threat to the network, then the ICON Dev team needs to work on this aspect until they find the solution.
My main point is that ICON Network needs only Main P-Reps and everyone who wants to be the Main P-Rep to apply for that, follow the rules, and be penalised if their nodes aren’t working as required.
The other important thing is to standardize the rewards for all main P-Reps to get the same amount of rewards operating the nodes only.

Then, the rewards from voters to the Main P-Reps can be separated and fixed for some reasonable maximum (for example 2.5% as you proposed already) in which if some Main P-Reps want to run multiple nodes and spread the votes on these nodes, so be it. ( this will bring a more stable network and additional cost for those who want to run multiple nodes anyway the % will be the same).

I think this will fix most of the issues and problems we are having now.

1 Like
#28

Telos (EOSIO)

has good model too. Since it is the same identical job for all BPs (P-Reps), so, Telos pays exactly the same for all top 21 BPs and then 50% less from 22 to Nr 45. No pay from 46+… Votes have no impact on rewards (Votes only decide rankings and Governance)…

All non-BP activities have Worker Proposal System (like CPS) model… In this model, no one is worried about the cost to manage P-Rep nodes…

In ICON case P-Reps ranked no 1 and ranked nr 22 have to do the same jobs (& same costs for running/managing a node), then it does not make sense to have different rewards…

There can be a limit be on how many P-Reps should be paid e.g. we have today 100 P-Reps. But 2 or 3 ranks can be defined in terms of Payment.

Rank A: Top 22 can have “same” pay,
Rank B: 23 to 50 can have 50% less than rank A P-Reps.
Rank C: the remaining 51-100 may have no rewards or can be very low e.g. 15% of what Ranks A gets. and the rest has no pay…

NOTE 1: The payment for Rank A should be auto calculated/adjusted monthly, considering the average USD value of ICX in the last 30 days… Whatever is the appropriate USD cost to manage a node can be agreed.

NOTE 2: If P-Reps do other jobs/tasks for growth/development of ICON ecosystem , then, it should be funded by CPS or ICON Foundation.

NOTE 3: ICON Foundation needs to be more involved and should have maybe monthly meetings with P-Reps? We have no idea how ICON Foundation members are selected and what they do? On the other hand Telos choose Foundation members by annual elections on the blockchain (that lead Marketing, Business Development, Growth, Strategy, Legal, etc.) and they have several monthly meetings and live Video Public sessions for the general public.

NOTE 4: Also no BP (P-Rep) can have multiple nodes or stake/investment in multiple P-Reps. P-Reps identities should be known to at least ICON Foundation to ensure that no one runs multipole P-Rep nodes or has an investment in multiple P-Reps. Also in the case of Telos, Foundation can not run a BP Node as the foundation has to be independent…

SAMPLE

image
image1096×952 145 KB

1 Like
Network Proposal to remove the not active nodes from been able to stake&vote for them