IISS 3 | P-Reps penalty mechanisms and bond management

Delegate / Validator Candidates Node Operation
#1

Hi,

This is very short post to explain the penalty mechanism that will be enabled in a few weeks with IISS 3.1 activation.

IISS 3 introduced the concept of bond (ICON Tracker). When a P-Rep does not behave as expected, this bond will be slashed (ICX will be burn) following specific rules.

You can learn how to post a bond and how the penalty mechanism is implemented https://icondev.io/icon-node/goloop/bond-management.

Feel free to discuss these mechanisms and how they can be improved in the future.

Thank you.

image
image1463Ă—795 174 KB

4 Likes
Changes to ICON Economic Policy (IISS 4)
Changes to ICON Economic Policy (IISS 4)
#2

We have been discussing as a team the implementation of the bond.

We are supportive of moving towards a 5% bond and the burn mechanisms proposed/approved.

We have a few thoughts we’d like to get feedback on from fellow P-Reps.

Concerns

  1. The current affordability of the bond for Main P-Reps and how this plays out when the bond is enforced.
  2. P-Reps are currently empowered to own the infrastructure but with ICONv2 only recently released, P-Reps are still too reliant on iconloop for software bugs (our node was recently down for 7 days waiting for iconloop - with a bond in place this would have resulted in a 80,000 ICX burn and we were not empowered to resolve the issue ourselves).

Progressive bond

We’d like to see a progressive move towards the implementation of the bond.

As an example, wait till we have a stable network for at least 3 months, then implement a progressive bond (e.g. 1% every 3 months)

This would give P-Reps time to be comfortable with the risk, stability of the network and empowered to up-skill where required.

We’d like to hear from other P-Reps on their views if they’re shared or alternate.

4 Likes
#3

I totally agree with you mate. I share your opinion and the 5% bond on the outset seems high and I was concerned for your node while it was down. I would totally support a progressive implementation like what you’ve noted here.

Look forward to hearing from other Preps as well and thank you for posting about this.

#4

We became one of the P-Rep less than a month ago (currently in #25). We became one of the Main P-Reps when some of the nodes were down a week back due to issues mentioned above.

We were extremely lucky to have received 4.7m ICX votes in a short period of time from our community. The new bond requirement will kill our participation because 5% (~225k ICX) is impossible for us to put in the beginning. Even though the idea of putting up bond is novel, we are not in a position for a bond neither are we in favor of it. As our friends have suggested, we can move forward with a progressive implementation but that too will be tough on our part.

Sorry to say but the bond requirement pushes out new communities to join in the governance. Is this something that we want? Definitely not. If the 5% bond requirement is implemented, GangstaBet P-Rep will not participate in the governance as it does not align with our community participation beliefs.

#5

So I am finally able to clearly read back and respond to this post. The slashing for missing blocks was NEVER approved through a network vote and I do not believe it should be included into 3.1 without a LOT more discussion. Here was the approved 3.0 ICON Tracker

I will personally push to reject any network proposal with missed block slashing rewards in it without a very lengthy discussion and compromise.

  1. We all experienced the most recent AWS/Google/Cloudflare outage that lasted many hours. This would have meant that ALL preps would have been forced to burn a lot of bond without having any possibility to save themselves. We cannot be required to have redundant hosting on multiple hosting providers “just in case”.

  2. The only way I would agree to a slashing on missed blocks would be if the length of time was 2 weeks. That’s how long we give people to vote/submit proposals/progress reports on CPS and it is a decent amount of time for a node to bet able to either fix it’s issues or relocate to a new provider.

  3. I will push to reject any missed block slashing until ICON 2.0 has been running bug free for 3 months minimum. Like Reliant node already said they were down for 7 days and we were down for 3 days all because of an ICON 2.0 chain software bug. There was literally nothing we could do to bring up our nodes, believe me we tried everything. Only the bug fix actually fixed the issue and our node came back up.

2 Likes
#6

At the moment with burn active. We still don’t have clear idea of how much our server cost going to be as a sub prep. Right now bonding feels like blind swing to hit or miss. Outside of always being against the bond system at the moment we can’t even estimate anything out of what we have.

1 Like
#7

I raised my concerns about bond slashing (with unforseen/unstoppable issues) a year ago, as well as offering a buffer/solution.

I envisioned P-Reps could use their ICX to generate a new token. That new token could be what is at risk of being slashed (instead of ICX). We would also mint addition tokens and hold them in a multisig treasury.

In the event that there was a network error, P-Reps would burn a disposable token, and not the ICX itself.

Screenshot_20211127-090729
Screenshot_20211127-0907291080Ă—1920 270 KB

Screenshot_20211127-090907
Screenshot_20211127-0909071080Ă—1920 226 KB

I personally agree we should wait to implement slashing until the network has these 2.0 bugs ironed out.

#8

Not sure if this was communicated elsewhere, but all penalties will be set to 0% at time of launch until the network stability increases. Therefore there is nothing to worry about in terms of posting the bond and having it slashed for any reason.

The very nature of how the bond impacts your rewards is progressive.

To elaborate, if all P-Reps posted a 1% bond, then all P-Reps would earn 100% of their rewards. If all P-Reps posted a 0.5% bond, then all P-Reps earn 100% of their reward. The 5% is more of a cap than a requirement. Our bonding system creates a competitive environment for ICX holdings, which is a good thing. The 5% is a cap on how much ICX holdings can actually benefit you. If you have more than 5% bond, there’s no additional benefit, but if you have 4% bond, and everybody else has 3%, you will be earning more rewards than everybody else. Hope that clears things up.

#9

There will be no slashing until the network is more stable, as mentioned in my previous post.

This is the most basic principal of any proof of stake network. Without slashing for missing blocks, all P-Reps could just turn off their nodes and still earn block rewards, assuming there was enough online nodes to even produce blocks. It is the only thing that incentivizes people to run nodes at all. It’s the reason that sub p-reps would run nodes, out of fear of being selected to produce a block and missing it. The slashing system was discussed here and feedback from the community was taken into consideration.

As mentioned above, all penalties will be set to 0 by default, then P-Reps can adjust them over time. I’d expect raising the penalties will be something that is voted on.

#10

Can the amount of blocks missed or amount of penalties before slash also be changed/voted on? I’m fine with slashing if the amount of time/number of missed blocks is larger/longer. 1hr is not enough time to really do a normal SLA in bringing back up a node, and especially if AWS goes down entirely like it has before. I mentioned a 2 week time period before penalty (obviously open to negotiations lol) but I just think the current amount of time is way to low.

#11

I think the biggest concern new P-Reps are having is that they / we will not be able to afford 5% bond. I know that it is not required, but from what you explained, P-Reps that can afford it will farm the majority of the rewards. I am aware that economically it makes sense, but it discourages new P-Reps with big amount of votes and not big enough funding to participate as Icon representative.

I would advocate for progressive implementation as already mentioned.

Regarding block validation penalty:

  • It should not be put in place until network has been stable for at least 1 month
  • It should not be in place until official mainnet node setup is enabling safe failover
  • It should consider bigger outages (AWS going down for hours)
  • It should extend the buffer time to approx 24h or at least 16hours to give enough time to notice, respond to issue and in worst case set up a new instance

Those are my 2 cents.

1 Like
#12

We suggest waiting for some time to test the stability (time test for 3-6 months) before the penalty raises above 0%!

1 Like
#13

Agree to ensure the stability of NW before application of penalty…

2 Likes