[Proposal] [Draft] Suggested changes to a few cosmological constants

Governance
#9

I also agree on @crainbf about downtime slashing. currently it is 0.01%, which is interest accumulated by around 6hours. I suggest this slashing to be 0.5%(about 2weeks of interest rate). But I think 95% threshold should remain for resistence from censorship attack. If we want tighter option, we can decrease the time window from 10,000 to 5,000(but i think it should happen much later than now)

#10

Here are my views (syncnode validator) on the proposal:

  1. Increasing the slashing penalty for double signing has both good and bad aspects: the obviously good aspect would be the increased responsibility and automatically a better infrastructure in terms of security for validators, the bad part would most probably be that only max top 10 validators would be able to attract delegations from the community, except if smaller validators are not offering some sort of guarantee. So I don’t think it’s a yes or no answer here, as it’s a pretty complex subject alltough it might not seem so at first sight. Also 20% is very aggressive, I think we should go there but not directly, maybe after we will have IBC up and running.

  2. Nothing to add to this point. It makes perfect sense from my point of view

  3. I don’t see any reasons why not doing it. It might be a little to early but besides that, I see no other reasons.

  4. It seems a little bit premature at this stage of the network. Let’s have a clear vision for the usage of the funds first and then let’s decide the amount of this tax.

Very important: I don’t think all these point s can go together on a single proposal and we will need separate proposals.

Thanks! Happy validating everybody!

2 Likes
#11

Thanks all for the excellent feedback. Based on response so far, and the upcoming introduction of parameter change proposals which will render future changes simpler, I think it makes sense to make three separate proposals in the near future:

  1. Add a proposal type to spend from the community pool, requiring the usual majority & quorum, to any Cosmos address. (leave the community pool tax as-is for the time being, until we see how it ends up being used)
  2. Increase "slash_fraction_double_sign" from 0.05 to 0.1 (more conservative than 0.2, I do recognize the concern about information asymmetry between new validators and delegators).
  3. Increase “inflation_rate_change” to 0.52, resulting in a maximum period of three months for inflation adjustments targeting 2/3 bonded.

Proposal #1 will be made before the next hard fork, so it can be included in that. Proposals #2 and #3 could wait until parameter change proposals are activated, but they would also be easy to include as changes in the genesis file after the next upgrade. I don’t have a strong opinion between those two options.

I think we should consider increasing the maximum validator count in the future, but I agree that doing so isn’t immediately pressing.

Thoughts on this segmentation welcome. Cryptium Labs will likely make proposal #1 in a day or two, and we are willing to implement it pro bono.

4 Likes
[Proposal] [Draft] Activate the Community Pool
#12

Has anyone proposed/discussed changing the unbonding process so its a constant unbond over X days (similar to how rewards are issued). I sense there is a lot of frustration with having to wait the full 21 days for ANY atoms to unbond.

A different approach would be to start unbonding atoms immediately at a rate which would see atoms fully unbonded after the full 21 day period.

This would also allow the network to increase the unbond period in the future without causing significant frustration, it would still protect against rash unbonding decisions with price swings, but would also allow delegators to access portions of their unbonding atoms before the full 21 days is up.

If technically difficult, a schedule could be set in 10% increments.

Edit: Couple of additional advantages:

  • This would also allow delegators to be earning partial rewards on unbonding atoms
  • If a delegator is in the process of moving his atoms to a new validator - the entire process could be completed without loosing any rewards - i believe this is important since we want to incentivise delegators to be able to relatively easily change validators without a big penalty.
#13

This is technically possible, but difficult, and it changes the security model in ways which would require careful analysis - I think it’s an interesting discussion to have, but definitely out of scope of this set of proposals.

1 Like
#14

Agreed - will try to write this up properly and put it together as a separate discussions
Thx

3 Likes
#15

I agree with few of the opinions above (hope i’m not too late to share an opinion):

slash_fraction_double_sign= 0.2 and community_tax=0.1 seems too high.
This would eventually lead to less Atoms to be staked to the network. It would lead to increased inflation rate at the end, but as the risk of bonding becomes too high for potential delegators, less stakes wil be involved in delegating and governance, making utility of atoms to go down.

But yes, increasing max_validator sounds like an idea to make a stronger network.

On increasing “unbonding period”, how much longer are you expecting? (some of the validators are offering to let delegators unbond without delay (i am not really sure how this will happen), so I am not sure if this would make a big change at all)

#16

From Ubik Capital point of view:

  1. For slash_fraction_double_sign, 20% slashing rate is too high. Such a high slashing rate could have a big impact on small validators.

  2. For “inflation_rate_change”. Let’s see some calculations before taking some decision.

  3. For “max_validators”. We can set the value to 150 validators but I don’t see any benefit in that. Now the last 30-40 validators are not so big to be self-sustaining given the number of atoms they own or which they have following the delegation. I think that after a while they will close their validators if is not a good business for them.

  4. For “community_tax”. Let’s use this tax to help small validators or le’s make another tax to help small validators. Let’s help a bit more the small validators.

Currently, there are more than 100 active validators but only 14 validators control more than 2/3 of the network so is not a real decentralization.

Decentralize Cosmos
#17

Hey @nodeateam & @UbikCapital - thanks for your feedback; just to clarify, the immediately proposed changes are only these:

Any thoughts on or concerns with those?

1 Like
#18

I disagree with comments regarding downtime penalties - we should have a proper implementation so that stake is slashed only if nr of validators that go down at the same time approach 1/3’th.

Only then should the penalty be increased. a lot.

We should also have automatic redelagation of stake for delegators - in case where their validator goes down.

To summarize in ideal case scenario slashing for downtime of a single node should be non existent if on protocol layer security via instant redelegation and penalty only targets 1/3 of nodes going down simultaneously. Delegators already bear a risk of loosing rewards and being penalized by inflation 0.035% a day, there is no point to punish them if downtime event does not cause network to be less secure.

Inflation change rate should IMO increase to target 1 week to 1 month for the 7% to 20% change. This mechanism exists to control the market which is extremely volatile thus inflation should be able to stabilize conditions in fairly quick manner.

1 Like
#19

Do we think the quorum requirements to spend money should be same as the current quorum requirements for votes to pass?

1 Like
#20

The current quorum requirements seem OK for now. Do you think it should require a lower quorum potentially (relative to a software upgrade proposal or the like)?

#21

Are you planning to put both #2 and #3 proposals up at the same time, after #1 is passed and hard fork is finished?

#22

Probably, though still as separate parameter change proposals.

#23

Final draft proposal “Activate the Community Pool”: [Proposal] [Draft] Activate the Community Pool

#24

Planning to pick this back up in the new year - I may split up the changes though - any further thoughts with the benefit of more mainnet experience?

2 Likes
#25

Hey @cwgoes, by my calculation, it appears that the rate that inflation changes is relative to the current rate. Not sure how clear that statement is, so here’s an example:

Inflation was 7.19% on Dec 30, 2019. If inflation could move between 7% and 20% in a year, that means it would change by just over 1% per month. However, tomorrow is Jan 30 and inflation is currently ~7.09%.

It appears that the rate of inflation is changing relative to a proportion of the current rate of inflation, if that makes sense. I think that the lower the rate of inflation, the slower it changes.

#26

Indeed, my original analysis was not quite correct, but I don’t think it’s relative to the current inflation rate - instead it is relative to the ratio of the current & desired bonded ratios.

From x/mint/internal/types/minter.go:

func (m Minter) NextInflationRate(params Params, bondedRatio sdk.Dec) sdk.Dec {
	// The target annual inflation rate is recalculated for each previsions cycle. The
	// inflation is also subject to a rate change (positive or negative) depending on
	// the distance from the desired ratio (67%). The maximum rate change possible is
	// defined to be 13% per year, however the annual inflation is capped as between
	// 7% and 20%.

	// (1 - bondedRatio/GoalBonded) * InflationRateChange
	inflationRateChangePerYear := sdk.OneDec().
		Sub(bondedRatio.Quo(params.GoalBonded)).
		Mul(params.InflationRateChange)
	inflationRateChange := inflationRateChangePerYear.Quo(sdk.NewDec(int64(params.BlocksPerYear)))

	// adjust the new annual inflation for this next cycle
	inflation := m.Inflation.Add(inflationRateChange) // note inflationRateChange may be negative
	if inflation.GT(params.InflationMax) {
		inflation = params.InflationMax
	}
	if inflation.LT(params.InflationMin) {
		inflation = params.InflationMin
	}

	return inflation
}

I still think that we should increase the InflationRateChange parameter - perhaps by a larger factor.

I won’t have time to pick any of these parameter change proposals up until after IBC 1.0, though - would the Governance Working Group be interested in taking some of these over?

2 Likes
#27

Right now the GWG is focused on education and helping others to formalize their proposals, rather than taking positions on or launching proposals. I could take a closer look at it personally, though!

1 Like
#28

Is the debate still open?
Do the latest developments, evolve the pro and contras of the current settings?
Keeping a dynamic consensus range in ratios may be the equilibrium pinnacle.