Parameter Changes - Raising the difficulty level a little bit for Validators

Governance
#6

fully agree.
So, Are we going to directly update these parameters by governance?

#7

Agree!
This is not a punishment.This will definitely make IRISnet more powerful.

#8

If a node is down, 50% tolerance won’t be enough for them. If not, 10% would be too much for it. Except the punishments, maybe we should also consider additional rewards for those been serving for a long time and no errors happened

#9

Great the first propo, sounds a good plan for update the skills for validators.

1 Like
#10

Thanks for the updates.

Fully agree!

#11

Good proposal, POS Bakerz will be supporting it! :grinning:

#12

:+1: Looks good and reasonable.
Umbrella supports this proposal.
:umbrella:

#13

Seems ok to raise a bit the bar for the validators.
Easy 2 stake will support this.

#14

To raise the bar a little, we think these parameters are a good place to get started, since any serious validator should be able to meet the new requirements with ease. Yet, by going through the process of changing one or two params as a community, we can raise awareness and familiarity about IRISnet’s wonderful and powerful on-chain governance capability, and prepare everyone for the more crucial two-phase on-chain software upgrade process which starts with voting on a SoftwareUpgradeProposal – such a mandatory upgrade is anticipated sometime in early July.

#15

Yes, based on people’s feedback here, we’ll submit one or more ParameterChangeProposal(s) for validators to vote on. Once passed, the parameter change(s) will take effect immediately.

#16

Agreed with this new parameters. Good proposal. This can only be beneficial for the network !

#17

Agreed with the new parameters. However, here is a question:

Because the new parameters increase the entry risk of the node, then how to prevent the new validators from being slashed if IRISnet has the same plan to gradually increase the number of nodes in the next few years?

#18

I agree . Time the ante is upped and may the best validators/setups win.

#19

We’ll soon launch a new community testnet NYANCAT, where new validators can practice, make mistakes and learn lessons.

#20

The value of Min Signed Per Window should be 50%-->70%, it means downtime is defined as missing 30% of total blocks in the same time frame, not 50%-->30%。

1 Like
#21

Strongly agreed:grinning:

#22

good idea,i have vote it

#23

Any reason to have doublesign punishment lower than downtime?

#24

Let’s consider one or more of the following parameters:

  1. Min Signed Per Window: 50% --> 70%
    Before: Downtime is defined as missing 50% of total blocks in about two days
    After: Downtime is defined as missing 30% of total blocks in the same time frame
  2. Downtime Jail Duration: 24h --> 36h
    Before: Downtime jail 24 hours
    After: Downtime jail 36 hours
  3. Downtime Slash Fraction: 0 --> 0.03%
    Before: No slashing for Downtime
    After: Downtime slashing 0.03%

1 & 3 feel reasonable to me. I’m not sure I support 2, especially in these early stages.

I think we want to incentivize validators to come back online as quickly as possible, rather than delay them from doing so.

1 Like
Proposal for reducing: downtime_jail_duration
#25

I agree with @chris-remus on the second point. What is the logical explanation for increasing the jail time duration. It might be one but I can’t seem to identify it correctly. Can someone advice, pls?

Beside that, I am fully supporting points 1 and 3.

1 Like