Yeah, from reading through it seems a very small token of a slash is most supported given the prospect of jailing as well. Can see the value of a very small slash… so that there is some (though minor) penalty beyond lack of reward.
Otherwise, I think these changes offer a great improvement to the network and setting clear values!
Lol, I am really glad to see that in the end, we have all these problems and issues with the incentivise the proper P-Reps we talk about so much a long time ago are beginning to be fixed or at least make a step in the right direction.
We were about to stop our node running soon as at this crazy situation worldwide it is not in our favour to keep losing money to pay for keeping our node running, while the rewards we receiving getting less and less in $ value measured!
As I said before we have to incentives only the P-Reps who run their nodes, set their bonding and secure the network properly as required and not those who just try to take advantage of the situation and do nothing and just collect rewards for that!
I am also glad to see that the right approach for that is to stop incentivising the voters if they keep staking with those dead P-Reps.
Regarding the minimum wage, I think it should be $1000 at least, taking the account that this is not just to pay AWS or other providers for running our nodes, but also for the work we do to monitor and keeps our nodes stable and running properly.
I like the idea P-Reps getting % of the staking rewards and then automatically sending the rest to all their voters.
I hope the implementation of those changes is done asap and not end of 2023 as planned as we cannot keep losing money to just run our node while the price of $ICX is hammered down from this crazy bitcoin bear market!
This proposal most certainly benefits ICON and will improve on the chain’s decentralization and security. We are happy to see that the new changes will omit “bad actors” taking advantage of the system and redirect voting power to more deserving validators.
We’d like to share comments from our own experience as a relatively new validator on the ICON Network (post ICON 2.0), as well as our two cents on the proposal above.
Notes form our own experience
Notes on this proposal
General Note
We have been running some simulations by taking into consideration that a proportion of inflation will be dedicated to:
Minimum Wage
We do not believe that the minimum wage should be profitable, but instead close to being profitable. It would encourage validators to either provide a service to compete for votes or at least invest more into the ecosystem before making a profit. It would also ensure that all validators set a reasonable commissions fee. We believe this is fair as the current threshold to enter the top 100 isn’t difficult.
Suggestions
Instead of coming at this with a sledge hammer, we propose that these changes be introduced gradually. A priority should be omitting rewards for inactive nodes and rewards for delegators voting for nodes with no bonds.
Our own tokenomics
The interests of the ICON Network outweigh the interests of individual validators. But since our community members vote for us because of our token model first and foremost, we’d like to note that this proposal will make it exceptionally difficult for us to continue with our token model. To do so, we would need to set exceptionally high commission rates. FRĀMD does not keep anything from the node rewards outside of the operating costs, the rest is given out to stakers, POL, and Treasury. Given all the above, we believe that (despite our best intentions) many users will prefer to delegate their votes to the P-reps offering the lowest commission rates. We can’t help but feel that this new system will emphasize the economics of delegation over the added value a validator brings to the network beyond security and decentralization.
I mostly agree with this, especially given market conditions.
Mostly agree, though overall looking to minimize ongoing technical debt. Where things are not coupled they can be done in multiple releases. I’d say minimum wage would need to be activated last, as it’s heavily dependent on the penalty system being active (otherwise it’s easily gamed).
I don’t know your token economics in detail, but this is how it would work I think. Right now, all validators take an implied ~14.5% commission. 13% inflation goes to nodes, 77% to voters. 13 / 90 = .14444…
So with that said, I think if you set your commission to 14.5% then all your voters should be in similar position to what they are now. Compared to most nodes on Cosmos that is high, but if there’s the extra FRMD token distribution or whatever other incentives you have, it could make up for the extra commission you charge.
Agreed with this way of thinking it. This should be a substantial help without being profitable.
I think the bond is a good mechanic to ensure that the node has skin in the game, and the 5% figure ensures solvency and commitment to the network. I think bond could be lowered once/if ICX price achieves much higher consistent fiat values.
I think we need a minimum wage, and we think that people from 1st to 100th should receive the same money every month.
Based on the current standard, the amount seems to be 400 to 500 dollars excluding labor costs.(Other p-rep reference costs)
Beyond that, I propose holding elections every year. Just as each country holds elections, it seems that we will vote for the p-rep who works more when each p-rep publicizes their achievements or what they will do in the future (roadmap) and receives votes.
Elections will be held every year, and p-reps who lied voted the following year will be punished with votes.
Voters must vote within a set period each year, and if they do not vote, they will automatically unstake.
Accordingly, what is most needed is an election site. I think there is a need for messages and bulletin boards announcing elections and p-rep achievements in a prominent place among hana wallets.
Voters get confused if there are too many p-reps participating in the election, so I think it’s better to allow only the 1st to 100th place to participate. In other words, it is impossible to promote elections from the 101st place onwards.
We also need to force multiple p-reps to vote. Just as we do not elect only one member of parliament, I think between 5 and 10 members is good.
This makes sense if you consider a validator node a crucial part of the network development.
The present consensus is that a validator goal is to produce blocks in a reliable manner, if they also want to willingly contribute to the ecosystem (for passion to the ecosystem, as a means of income, or a combination of both) that’s an optional task that the network should not mess with (free market does a better job in my opinion).
Hi there,
I agree with most of the points with the exception of slashing jailed P-Rep for missing blocks.
Slashing should only be done to malicious actors.
More importantly, we can already see the rise of commission based P-Rep models where direct or indirect rewarding (ICX gained used to buy native tokens which get distributed to voters) convinces profit seeking voters (majority) to delegate votes to them.
Nothing wrong with that BUT, consequence of such model is gain of immense voting power both on network and CPS level, essentially driving towards centralization or monopoly if you wish.
This is very much unhealthy for Icon blockchain, its decentralization, future growth and for part of community that do not seek profit first, but have mindset to grow value of Icon through contribution (dev, marketing, media, etc…) and rather profit from the consequence of their positive intention.
But of course they can go to CPS and get funding there, this is what CPS was meant for.
Was it though?
Is it working?
Do P-Reps or projects that have binded their economic model to validator rewards still leave funds available for others not so fortunate to be able to create such circular economic models?
CPS is more or less emptied, big projects that were hit hard (especially ones with no validator commission model) have no choice but to turn to CPS despite unwanted consequences.
It feels like we can only dream that ICX will pick up and $ liquidity will rise in order to be able to sustain apetite for growth in un-explored directions.
Let’s have a healthy, constructive and respectful conversation around how and if should voting power gained from beforementioned commission model be separated from network and CPS voting power on top of well detailed breakdown by Scott.
Edit: grammar
Overall I don’t have a strong opinion on this as much as I think that nobody in our community (including myself) has the knowledge or expertise to directly challenge what Tendermint has worked on for years. The Cosmos ecosystem has the most robust validator set in the industry, and they have slashing penalties. If ICON is to be described as a secure hub for cross-chain messaging, I think Cosmos has a good model for that. In order to move the conversation along I’d be happy to start with something extremely small and work our way up if necessary. Personally it would just be hard for me to justify no slashing when speaking to any 3rd party about ICON’s consensus mechanism.
Overthinking this is part of why we are in our current situation imo. ICON tried too hard to make something different and new without the expertise, and now years later we are still spending time (and dev resources) trying to fix it. Would prefer to go as close as possible to something that has been out in the wild for a while, then focus our efforts on the xCall service and cross-chain development/incentives.
And as for the impact on the CPS, let’s keep that as a separate discussion from network consensus. I’d suggest here.
https://forum2.icon.community/t/cps-improvements-discussion/3124/10
They have robust validators because they mostly have same validators across chains with heavy vote weight. Even with that not all run IBC relayers because there is no incentive. They are not that secure since protocol don’t have any shared security kind of system. It’s safe as their weakest chain they have. It’s just makes the cross chain communication simple and without complications because of their standard. It still lacks a lot. They are trying to change a lot of aspects to fix these short comings(atom 2.0).
Hey folks,
It’s been a while, but this thread hasn’t been forgotten. Been waiting for dev resources to be available from Parameta, and that time is approaching. Before requesting them to build these new features, I’m thinking of doing an on-chain “temperature check” text proposal on whether the current validator set would adopt this software upgrade as proposed. Lydia Labs plans to submit it sometime next week, but wanted to give everybody a heads up.
The “temperature check” proposal would not include anything related to specific numbers, just the features themselves. Specifically:
I think we should specifically fill in the missing _ before having any work done so it’s not wasted but I’m glad to see this will be progressing. Aka 0.05% not the previously 5% slashing that was originally discussed before ICON 2.0 prior to this comments of this thread. I’ll go through the thread and fill in the _ with my thoughts.
Yes, Cost of running an ICON 2.0 node should be the basis to consider the final value for the “minimum wage” as stated above by @espanicon
Is there a timeline on this? I personally think this should be put into motion soon.
My 2 cents on the cloud centralization / AWS issue, I don’t think anyone should worry about it. People worry about AWS being hacked but there are way bigger fish in AWS / other clouds that it is really of little concern to ICON.
As far as the minimum wage is concerned, I think running a basic node on AWS should dictate what the minimum wage is. The instance Fidel mentioned (t3a.xlarge) is sufficient with the associated drive space putting minimum node costs at $320/month. I think maybe +25% of that ($400) should be good IMO.
Hey Geo - thank you for the feedback. The reason that we’re doing it this way is because it will likely take a lot of discussion to decide specific numbers, which would delay development. The numbers can be set to 0 if a decision is not finalized prior to the upgrade, however, if we don’t start any development, it could significantly delay the implementation timeline.
Agreed
That’s what we’re looking to do here! Timeline would be Q3 iirc, not sure if that includes testing.
Here is my input. We are in process of leaving the chain while a lot of prioritised operation delay that. Recently I am about unregistering process before all this. In summary even with these changes it doesn’t give us any confidence at operational level for icon. In addition to that when this proposal first come up. I already state how it is. Cosmos is aware their structure need to be improve and working on it. They now what they utilize doesn’t work. Icon just cloning everything from cosmos is funny and shows how these changes happen/decided upon.