Additionally, it’s extremely easy for ICX holders to post a bond for a node if they so choose. Even in an extreme example, where let’s say 10% of delegated ICX wants to support a P-Rep that holds 0 ICX for whatever reason, those ICX holders can use their ICX to post the bond on behalf of this 0 ICX holding P-Rep very easily to make sure this P-Rep, that they want in power, can actually stay in power despite having 0 ICX of their own.
Oh, I wasn’t aware of this. So anyone can post a bond on behalf of a node?
Block Rewards
IISS 3.0 removed Block rewards ,we believe this is the wrong decision. Block rewards encourage validators liveliness, the 17.5% of total rewards allocated to P-Reps should be split based on vote percentage and round production, maybe 70% vote / 30% reward
Block rewards in themself work as an incentive for a validator to keep their node online, removing them removes this incentive and we introduce a penalty instead. Is a penalty better than a reward? If a validator gets jailed for failing to produce they would lose rewards, the jail time could be the current round and possibly the next 24-72 hours or whatever might be deemed a penalty enough to the validator. No validators want to lose rounds as they lose income as a result, as well as reputation.
Self bond with Slash vs missing rewards, in IOST if you miss 10 blocks in 10 minute round you are jailed for 24 hours, that is incentive enough in our opinion as you missed out in all rounds for the day. The same is true on IoTeX with the addition of voters rewards excluded, if you miss blocks your rewards are nullified for 6 epochs(6 hours) as well as your voters , but you do not lose bond you loose rewards and so do your voters, this encourages liveliness without bond slashing. Slashing of voters tokens we believe is not good under any circumstance. There can be many reasons that validator misses round and they are not necessarily malicious. It also does not play well in Enterprise Blockchain deployment scenario.
Re-introduce block rewards for IISS 3.1 (ICON 2.0) , 70% vote / 30% block rewards of the proposed 17.5% overall
Limit slashing to producer if its maintained at all
Block Production
Currently we have 22 Main prep in round that last 24 hours, all you need to censor transaction in theory is 1/3 and 2/3 to create invalid, as the vote stagnation means this rarely changes it can cause to much influence. ICON 2.0 introduces the idea of inclusion of sub prep which is good but some improvements
With shorter rounds and higher selection of random the network will have greater security and decentralisation. If you consider the likilness you can get 1/3 or 2/3 of the current round influenced under this it would be nearly impossible to organise.
Random selection of 7/10 from top 10 , 8/20 from 11-40 , 7/20 from 41-100
Code is Law
The current constitution which prevents teams like Sesameseed or Metanyx creating their own economic design and should be removed, it is not enforceable or managable if it is not enforced by code is law principal. If a validator wishes to share their rewards with their voters they should be allowed to do so without an offchain rule. This is not vote buying it is a reward , the validator is not necessarily receiving additional rewards if are passing it on. It may lead to teams being voted higher and as proposed above may include them in more block rounds and if B1 is re-instated they might be passing those on their voters but is this a bad thing?
Constitution should be replaced with Code is Law
Inflation
Inflation should be set to 2-3 percent of total circulating supply with ability for Preps to vote on increase with a maximum of 5% and a minimum of 0.1% . All top 100 elected nodes should have vote with 2/3 required to pass on a 1 vote each scenario. An elected member of parliament (in the UK) has 1 vote, they are not weighted based on how many votes they received and this should be maintained as exists with top 22 but expanded to all elected 100. To much power is given to a handful where as all 100 are considered elected, if they are elected than they should be given a vote.
0.1 to 5% inflation
Top 100 1 to 1 vote on change of inflation
Bond Requirement
Bond requirement could be used to define Capacity of total vote , it should not create an unnecessarily high barrier to inclusion. Current Main Preps who earn considerably more already have advantage to others. AION uses a Bond to define capacity but there is no slashing of the bond.
Bond slashing if maintained should be a percentage of the bond vs a given amount.
Bond to define capacity
Percentage of a bond slashed if slashing must exist
Voters should never have their tokens slashed
CPF
We believe that DPoC has generally been proven not to work, we saw this where main preps are unwilling to use there rewards to fund development and instead requested grants on top of what they were already receiving. The general idea of DPoC seems to be more of marketing than reality as proven today by the need to reduce P-rep rewards and create a Grant system.
CPF is a replacement of the grant system, we agree this is a better approach than a grant system.
1 million ICX cap as proposed, must be distributed or burned instead
2/3 of 100 must vote and agree on any funding (not just top 22, why are they considered elected if they do not get a vote)
We also believe in the KISS = Keep it Simple Stupid , ICON Foundation has listened to the community and tried to create an ecosystem that is sustainable around the protocol, we believe however some parts were unnecessarily complex and more simple model should be adopted .
Self bond with Slash vs missing rewards, in IOST if you miss 10 blocks in 10 minute round you are jailed for 24 hours,
On ICON, we have both. The “Jail” penalty is the Validation Penalty, which is assessed after missing 660 blocks (~20 minutes of downtime). After suffering 5 validation penalties out of your last 30 terms, which translates to only 83% uptime, you will be slashed 20% of your Bond.
We can’t simply have jail because that creates an issue. If enough P-Reps are consistently down and there is no slashing penalty, they will continue to get out of jail and continue to fail to produce blocks. Yes, we could trigger another condition to get out of jail, like sending a transaction as suggested by @Edouard_Stakin, but after further discussion with ICON the “jail + unjail transaction” is an added feature that will slow down ICON 2.0 development and migration. We can add this feature after launch if we find it to be necessary or a strong improvement.
Re-introduce block rewards for IISS 3.1 (ICON 2.0)
70% vote / 30% block rewards of the proposed 17.5% overall
Any reward that is based specifically on running a node (flat reward per node, reward per block-producing node, etc. etc.) incentivizes a Sybil Attack. I don’t want to be in a situation where 10 Main P-Reps are operated by 1 entity and we just don’t know. We don’t need to pay people extra money for executing a Sybil Attack. On top of that, now that we are pursuing 3 rotating Sub P-Rep slots, all nodes will engage in block production anyway. The long term goal is to remove Sub P-Reps and only have Main P-Reps. The Validation Penalty (Jail) incentivizes uptime as well. If you suffer this penalty, you face opportunity cost for the term you are in Jail.
Shorter rounds (every hour maximum)
Random selection of 7/10 from top 10 , 8/20 from 11-40 , 7/20 from 41-100
This is an interesting thought that we will likely pursue / look into after ICON 2.0 launch. Making adjustments like this will take some dev resources to research and develop a different consensus algorithm and I’d rather have ICON focus all resources on migration to ICON 2.0.
Constitution should be replaced with Code is Law
We don’t have a constitution FYI and overall I agree here.
0.1 to 5% inflation
Top 100 1 to 1 vote on change of inflation
ICON is 1 to 1 vote AND stake-weighted vote. I don’t see the purpose of making it less secure by removing one of those thresholds. It will be Main P-Reps only, however, Sub P-Reps will be rotating in (3 per term), and the long term goal is to have only Main P-Reps as mentioned earlier. As for inflation rates, we are shooting for as low as possible. I like the suggestion of capping at around 5%, we can add this cap or something similar.
Bond to define capacity
Percentage of a bond slashed if slashing must exist
Voters should never have their tokens slashed
Everything you said here is already true.
1 million ICX cap as proposed, must be distributed or burned instead
2/3 of 100 must vote and agree on any funding (not just top 22, why are they considered elected if they do not get a vote)
1M ICX cap is already agreed and burning any extra is already agreed.
CPS will be managed by anybody that wants to sign up to manage it as mentioned on this thread.
Hi @BennyOptions_LL, Great proposal and thanks for putting it together.
Nothing to add to both point 1 & 2.
Additional recommendation around the inflation pool split categories; would it make sense to hard code a minimum and maximum expectations, this will fix expectation and enable better business and project planning with an aspect of certitude around earning vs cost.
While I agree most of this part and new updates finally sub p-rep votes mean something with managing CPF issue is entry to 100 is near to nothing. Even though I agree to this approach without fixing the heavy vote % on top that would be suicide.
Hey Reda - this is a good idea that we had been debating internally. Thank you for sharing your opinion, and when it comes time to decide actual allocations we will also discuss minimums / maximums for each bucket
Any reward that is based specifically on running a node (flat reward per node, reward per block-producing node, etc. etc.) incentivizes a Sybil Attack. I don’t want to be in a situation where 10 Main P-Reps are operated by 1 entity and we just don’t know. We don’t need to pay people extra money for executing a Sybil Attack. On top of that, now that we are pursuing 3 rotating Sub P-Rep slots, all nodes will engage in block production anyway. The long term goal is to remove Sub P-Reps and only have Main P-Reps. The Validation Penalty (Jail) incentivizes uptime as well. If you suffer this penalty, you face opportunity cost for the term you are in Jail.
How will the sub-preps pay for adequate server resource on only vote based rewards? consider a random selection of 3 out of 23-100, you will have teams who cant afford to have adequate server on line, in current market anyone >50 probably cant run recommended server spec without loosing money. We are proposing more dynamic vote weighted rotation and to reward block production so people can cover costs of running server. You may never get into rotation if it is 3 slots and sub prep with lower vote wont be able to afford it
We do not think having block rewards incentivizes a Sybil attack if there is no way to predict if you get into a round, it only encourages more active nodes and network liviliness.
This is an interesting thought that we will likely pursue / look into after ICON 2.0 launch. Making adjustments like this will take some dev resources to research and develop a different consensus algorithm and I’d rather have ICON focus all resources on migration to ICON 2.0.
We really hope you do consider it, hard to change later, do you really want only network with top 22 and 3 rotating slots long term. Rotating more frequently with a weighted random selection as proposed in conjunction with block rewards would create more engaged sub-preps. It also distributes rewards more fairly outside of the top 22.
We don’t have a constitution FYI and overall I agree here.
If so can a P-Rep share their own rewards with a voter? if not why not?
Voting rights
Sub-preps should be given a vote if they are considered elected, if you have 100 elected candidates as you do in ICON it should be the same as in parliament(UK), every elected MP in parliament gets to vote not the 22 who have the highest amount of individual voter and the rest have no vote. The 100 seats should equate to 650 seats in parliament, the 650 have equal voting rights within the house of commons for any bill. Maybe its time to not distinguish between the two (P-rep vs sub P-rep), you are elected or you are not with the caveat that a higher vote gives you higher probability of being in block production (taking into account populous vote for block production only)
@BennyOptions_LL I agree on some of the points @metanyx share and I think there is a way to tackle it. Hard capping vote amount.
About rotating part I agree but it still drop down to most of the vote gathering on top I don’t think it’s going to be possible without server cost while that’s still can change. Same for vote rights case. So if we cap the vote amount to some number. It will force community vote towards to lower preps if some team have that much of their holding they can create a second one self stake and have 2 vote while they can’t gather vote over time because they are at top region. That’s also help a lot with foundations effect over onchain decisions and all. If I count icx station with foundation and didn’t count 2 main prep all other preps need to be together to make decision against foundation and station. For sybil atack issue I remember foundation self stake 24m right now foundation have 49.3m votes considering this vote goes towards other preps again sybil attack become less possibility foundation will still have more votes than any other prep but in the end not going to be that hard to pass something foundation doesn’t agree. For sybil attack instead of making it every sub prep we can do like every sub over 4 million for example can have vote + can join to sub prep rotation. Right now that’s literally 0 sub prep but that was a basic number I come up considering circulation numbers. Considering hard cap 8 million main preps have 238m vote that left 62m vote outside 22 considering all 22 become 8 million hard capped prep
with 4 million cap that still equal to 15 sub joining in to block production cycle and voting. Foundation have 4 votes in this format with 8 fully maxed prep account. It’s something I come up with now but it can be calculated and become something for the future.
White this on mobile let me know if anything about it is not clear
If we put a cap on the number of votes a team can get, then literally every team that reaches that cap will simply launch a second node. The second node can easily climb ranks, as the larger node will delegate all rewards to the smaller node. As the smaller node grows, other community members will vote for it. I don’t see how it solves the issue, all this does is force whales to create more nodes, which we don’t want to happen.
If I were any team in the top 10, I would immediately create a new node if we pass this rule. Then I would delegate all my ICX to the new node until it grows to the cap.
Also, even if we did want to go down this route, I don’t see how it’s possible logistically. We would need to manually remove delegation from the top nodes, which will hurt the voters that support them for no reason. But open to ideas just in case this ends up being the bes
Not sure hardcap makes sense without some other method to reduce team wanting to spin up another node, one idea that AION has is that your bond creates a capacity of your node, it can however also be used as Stake , maybe it shouldn’t be for reasons below.
So imagine this, you have Bond, it is 100k ICX, you get capacity at x10 (pick the multiplier) your bond.
100k x 10 = 1 million capacity
For you to spin up multiple nodes you need a bond for each defining your capacity, it also means you have skin in the game and you are not necessarily rewarded for your bond meaning doing so reduces your overall reward. If we had 1 million ICX , it would be better for us to do
250k ICX bond = 2.5 million ICX capacity <— no reward on your 250k bond
750k ICX staked to my validator <-- rewards on teams own holdings endorsing your validator
It creates a limit defined by your bond but also does not encourage you to create multiple nodes as it limits your overall ROI on your own holdings. Excluding bond from rewards with a capacity might be the answer
In case of scenario of a slashing penalty (whatever that might be) , the slash should be a percentage of your bond. There should be a minimal bond but not to high for lower Preps, It does however limit the ability for a team without large internal holdings to move up the ranks so there is that caveat.
As stated previously, rotation and block rewards we believe are necessary to pay for nodes to run adequate hardware, currently 50th ranked node generates about $30-40USD a day ($900-1200USD monthly). There is no way >50 can afford a server adequate to pay without block rewards.
Block rewards were removed mainly because they only were applied to top 22 (they already get more in vote rewards to begin with) and to subsidise the CPF (correct us if we are wrong). If we change the parameters to include more rotation than 22 (as proposed and as in IOST design basis) this is no longer the case that only a few get the block rewards as rotation will occur more frequently and more Preps get a proportion of block rewards to pay for there hardware overhead costs.
In your proposal the opportunity cost associated with a bond is a further deterrent to setting up multiple nodes. In the current system design, the bond will indeed earn delegation rewards. Anything bonded for P-RepA will also be delegated to P-RepA and therefore earn rewards.
Personally I think that in this situation the cost outweighs the benefit, but if you feel strongly we can vote specifically on the topic of whether or not a bond should be able to be delegated.
As for the concept of capacity, that’s already how it is designed, so no need for any extra work or development on that topic unless I am misunderstanding you. We have the concept of “bonded delegation”. Let me know if you are unfamiliar, it was explained in the IISS 3.0 thread
If a team own their 100% of their vote yes that’s possible. If they have some votes from the community they can’t. The point I was making is forcing for vote concentration at top to split and make votes equal over certain vote and make it decentralized. If some team self staking fully they can still do that but they can’t keep gaining more power on the network by community vote by retaining their position. Biggest example of that is foundation node having more than 24m vote for their 24m self stake. Something like that force that 24m vote to split to others. Same for non-active votes on top preps. Under these changes foundation also will have more beatable vote power on the network in the long run. Because right now foundation just keeps gathering more vote. I am not about it’s earned or not it’s just not helping decentralization in any way.
You are right that it is more beneficial for whales that control their own ICX, but it would still happen for teams that have maxed out their delegation.
Example: P-RepA is a high ranked community voted team. After a few months they reach the cap. The team for P-Rep A will then deploy P-Rep B. P-Rep A will begin using all future rewards to delegate to P-Rep B. P-Rep B will rise the ranks through a similar process, then they will deploy P-Rep C when P-Rep B inevitably reaches the cap.
Whether or not you think this is a realistic concern is up to you. If you think a cap is the answer, then you can propose that. Come up with a specific proposal and ICX Station can submit it on your behalf since Sub P-Reps can’t submit proposals right now. Then the network can vote on your idea.
I don’t see that as a concern. If you check the numbers I don’t think you will see that way either since the bond is already coming not to mention that takes 333 months with saving up all the rewards not even counting in server cost. 17 year to create a second prep to gain one more vote power is a very long process don’t you think. 28 years to max it and 3.5years to collect 1million icx. If that system got implemented 1million icx will climb them to nowhere. I really don’t see it under any circumstances maybe I am missing something if you want to explain that part.
Alright, these are fair points. I’m going to consider a cap on the percentage of the network one node can receive in terms of delegation. Perhaps the pros outweigh the cons
Yes that’s the case imo. I have 2 approach for that capping. These approach considering 8m icx max cap I come up with after some basic calculations max cap can be anything while system is getting implemented. One of them is over 7.8-7.8 million icx prep having 1 vote. For under 7.8 million icx preps making it 4 million or something like 5-6 million to avoid preps splinting their vote between two preps to duplicate their vote power. Other way is making 7.8-7.9 million icx prep node 2 vote power and making over 4 million vote 1 vote power in this way there is no benefit of split etc. In any of these case any sub with one vote power consider elected have equal say in cbp system and can join node rotation since that amount of vote should be enough for covering their server cost. Foundation also retain 24m split them in to multiple nodes still have high % in every vote on chain without single-handedly dominating it or keep gaining more power by community vote.This way votes get in a way forced but split between multiple parties and including subs over time with rotation as mains will be much easier.
2: We like to see some upper limits on voting weight so that there should not be so much difference in voting weights. (We like the idea of ETH 2.0 - though there may be some issues with that)
