On ICON 1.0 we never implemented any sort of burning penalty, however, we have plans to implement a burning penalty on the bond of the P-Rep. Please see the details below and let us know if you have any strong feedback you would like us to consider:
Validation Penalty - This is currently live on ICON 1.0 and it will be the same on ICON 2.0. After missing 660 blocks, a P-Rep will be removed from block production until the next term. There is no burn associated with this and there will be no burn associated with this.
Accumulated Validation Penalty - This will be a new penalty. If a P-Rep receives 5 Validation Penalties within their last 30 chances, where a chance is defined as serving 1 term as a block producer, the P-Rep will be removed from block production and 20% of their bond will be burned. This penalty will be enforced on every validation penalty from 5 or more within the last 30 chances. In other words:
If a P-Rep getās 5 validation penalties in the last 30 chances: burn 20% of current bond
If a P-Rep getās 6 validation penalties in the last 30 chances: burn 20% of current bond
If a P-Rep getās 7 validation penalties in the last 30 chances: burn 20% of current bond
etc. etc. etc.
The goal here is to remove a down node from block production since ranking is based on the amount of bond posted. If you are a Main P-Rep suffering this penalty over and over again, eventually you will drop to Sub P-Rep status as your bond continues to be slashed.
Overall, it is important for network stability to remove downed nodes from the block production rotation, and slashing the bond until the node drops out of rotation is a less harsh way of doing this versus complete disqualification.
Governance Slashing - this will stay as we agreed in IISS 3.0, minus the slashing associated with the Contribution Proposal System since the CPS management is no longer mandatory as described here.
There are hundreds (at least, probably thousands) of casual crypto/ICX holders who think we have a splashing penalty implemented for stakers (as originally planned). I average a DM/reply every week about this subject (and in the past it was 10x that).
My wish, as an arbiter of the greater community, is once a new system is agreed upon, we all update the community together. The general fear of a burn is scaring ICX investors away.
Myself personally, I am very happy to see the bond/slashing risk move from ICONists to P-Reps.
On the accumulated validation penalty, we support adding a slashing penalty for repeated downtime. However multiple 20% slashing penalties seems a bit harsh.
Would a jail mechanism that turns one slashed node from active to inactive make sense in the case of ICON? Once jailed, the node would be disqualified from block production unless it sends an unjail transaction in order to qualify again - akin to a partial disqualification. During the disqualification time, the node and its voters do not earn inflation rewards anymore - which also adds an incentive for voters to monitor to who they delegate.
We can consider a one-time 20% penalty along with ājailā, but overall this penalty should be harsh given that the network is relying on block producing nodes for hundreds of millions of dollars to be secure. Having a node down for 5+ days is quite unacceptable. Also, remember that it only happens as often as you are a block producer, so for a high ranked team you could get slashed many times, but for a low ranked team it would only happen a few times maximum.
Another option could be getting ājailedā then paying some fixed fine to become āunjailedā, maybe something like 10,000 ICX or some percentage of the delegation of the node. Iād just want to check with the ICON team regarding development complexity of adding these different states to the network. The more states / conditions we have on the core network, the more bloated every calculation can become
I like the idea of the jailed team not earning rewards but Iād want to keep voters rewards safe given the effect voter fear has shown to have. Many vote for the ICON Foundation because they are scared of getting burned imo, even though burning isnāt even live
Wouldnt a ājailā option for sub-preps turn them into what we have now - preps that earn their voter rewards without running a node? Maybe the voter rewards should be cut during jail time as well if such option is implemented?
How would the validation penalty work for sub-preps at all? If a penalty is applied for missing validation of 660 (I assume subsequential) blocks and the sub-preps process blocks on a rotational basis, isnt that a huge amount of time until a penalty is introduced?
What would count towards that amount of blocks - will it be counted as an overall period of 660 processed blocks on the chain (where a sub-prep could have processed 1 block only in example) or 660 blocks allocated to the sub-prep (which could take months(?) for one 1 validation penalty to be applied)?
Also slightly off-topic but since we are implementing more requirements for the sub-preps, should there not be an incentive for being a top 100 prep and having to run a node (as outside of the 100 you would receive your rewards without having any responsibilities)?
Wouldnt a ājailā option for sub-preps turn them into what we have now - preps that earn their voter rewards without running a node? Maybe the voter rewards should be cut during jail time as well if such option is implemented?
If we use the jail idea the node would not earn rewards while in jail as proposed by Stakin.
How would the validation penalty work for sub-preps at all? If a penalty is applied for missing validation of 660 (I assume subsequential) blocks and the sub-preps process blocks on a rotational basis, isnt that a huge amount of time until a penalty is introduced?
Sub P-Reps that are selected for rotation are added to a Main P-Rep slot for an entire term (~24 hours), and 660 blocks is approximately 20 minutes. If the Sub P-Rep is down when it is selected for a term, it will miss 660 blocks in a row (and suffer the Validation Penalty) unless the team can get the node up and running within 20 minutes of being selected.
What would count towards that amount of blocks - will it be counted as an overall period of 660 processed blocks on the chain (where a sub-prep could have processed 1 block only in example) or 660 blocks allocated to the sub-prep (which could take months(?) for one 1 validation penalty to be applied)?
Just to reiterate again, Sub P-Reps are not selected to only produce 1 block, they are selected to produce blocks during an entire term. So if they miss 660 blocks in a row during their term they will receive the validation penalty. That will count as 1 chance and 1 penalty. Then the next time they are selected (which will likely be many days later) it will be chance number 2. If they successfully produce blocks, the Sub P-Rep will have 1 validation penalty in their last 2 chances.
Also slightly off-topic but since we are implementing more requirements for the sub-preps, should there not be an incentive for being a top 100 prep and having to run a node (as outside of the 100 you would receive your rewards without having any responsibilities)?
In our current system Sub P-Reps below rank 100 do not earn rewards and this will continue to be the case in ICON 2.0.
What will be the server requirement for the nodes btw. Considering subs specially low ranks not earning that much. In our case we run 2 node one for prep which has 0 function in reality one for tipiconbot with much better specs than our prep node. We will probably keep them apart while thats a consern imo for under 50 rank teams maybe much lower but at some point down there vote weight drop significantly
Thanks for the detailed response! It all makes sense.
I also agree with the jail proposition but I agree with you as well that the voters should not be penalized - we have already tried a system where the voters are penalized and even the plans for it were enough to push buyers away (and are still pushing some away even though it was never implemented)
I think I would propose a higher number of validation penalties before slashing. Maybe remove the ālast 30 chancesā part and just go with a consecutive number of misses? Like if someone misses 10 in a row theyāre not really trying to get the issues fixed and probably deserve the penalty. But a new p-rep trying to get things set up/stabilized could pretty easily miss 5/30 while realistically trying to get their node working. I think the 5/30 number might hurt the wrong people. I feel like it would mostly hurt or prevent/scare off new p-reps, whereas if it was something like 10+ consecutive misses it gives them some more leeway to make sure theyāre stable while at the same time removing the non-functioning (and not trying) p-reps from production.
Even just something that would probably rarely be used like 20+ consecutive misses would get the point across that your node needs to be running with maybe a little less fear that may keep some people away. Maybe Iām not thinking about this from all the angles though.
Also, Iām assuming there is going to be a grace period after the update to 2.0 since there will most likely be some stability bugs to get worked out?
Overall I hear your sentiment and lean toward less harsh penalties since theyāre meant to be deterrents and hopefully rarely used. As for your specific suggestions, I think you are perhaps underestimating how hard it will be to suffer the penalty as currently proposed and might be missing some cases where āin a rowā style penalty systems could create a bad scenario. As a brief example, you could have a node with only 20% productivity never get slashed at all (O = online, D = down: O, D, D, D, D, O, D, D, D, D = online 20% of the time with no penalty). Something like this could happen from running really poor infra. For Sub P-Reps that rotate, this becomes even more of an issue since they may only produce blocks every so often.
I will speak with @ICON_ADMIN and the ICON devs about your suggestions, which are certainly appreciated, but overall the internal evaluation with developers is that 5/30 is even still fairly loose considering how important it is to make sure our network can produce blocks 24/7.
I understand that youāre probably a bit concerned because of the stability of our current network, but I am assured that ICON 2.0 is far more stable and should not require as much maintenance. And yes, there will be a grace period and testing of ICON 2.0 so people can get their nodes running and comfortable with the software.
Is this per turn or per term if we consider it as a turn 22main node creating 5 blocks consecutively means 10 seconds per prep 220 seconds till turn come again I donāt see any significant issue fixed under many turns. If we are talking about terms than 5 consecutive terms is like 5 days which you canāt test something prior which is not that unlikely to happen imo. In general, I didnāt get how the system calculates and check what so I will keep reading with more info gets clear about it.
Validation penalty = missing 660 blocks in a row - this removes you from the validator set for the remainder of the term, therefore itās not possible to suffer more than 1 validation penalty per day
Accumulated Validation Penalty (this is what we are talking about) = 5+ validation penalties / 30 terms as a producer. This implies that you start getting penalized when you are getting validation penalties over 16% of the time, which is quite bad.
I say ā30 terms as a producerā because Sub P-Reps will rotate as producers in ICON 2.0, so it will be much longer than a 30 day period for Sub P-Reps.
Ok make sense my only issue is for subs itās so random letās say you had issue got penalty than fixed it or you think you fixed it and hit one by one random one again I am not sure how subs can coordinate it while in general, Itās very sensible.
I fear weāre not thinking ahead enough about possible worst case scenarios. As we have seen code failsā¦ thus Iām starting to oppose the idea of burning a nodes bond.
Can I suggest an alternative please?
Can we make a seperate currency āXā (not for public sale). Production penalties instead incur fines. These would be charged as a fine to a node. If a node incurrs a high amount of fines then their node would be stopped until the fines were paid (to be paid in āXā). ICON P-Reps could manage a few multisig wallets with a large reserve of this currency, or we could mint more on a network vote. This would give us the ability as a network to reimburse anyone for wrongly issued fines without costing the network ICX.
Then weād get security + an extra layer of safety for P-Reps bond.
Hey @NorskKiwi - this is an interesting idea and appreciate the suggestion, but would require a significant amount of extra work (probably several months of work) not only on the development side but on the economic design as well. I donāt think it brings enough tangible value over the current design to justify the additional work, but if you feel strongly we can consider this system after ICON 2.0 launches and can vote on it.
I am not sure how subs can coordinate it while in general, Itās very sensible.