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

Note: In this post I’m representing Cryptium Labs, not AiB. All suggestions are provisional and up for discussion, no proposals have yet been made. The Cosmos Hub state machine has many configurable parameters, such as unbonding time, maximum validator count, inflation rates, deposit requirements, etc. which can easily be changed. The original values for these parameters, which have not been changed since launch with the exception of “blocks_per_year” , along with justifications for their original values, can be found here . Now that the Cosmos Hub has launched and is transacting real value , it is the view of Cryptium Labs that we should revisit many of these parameter choices, both from the lens of operating a stable network in the mid-term and planning for an exceptionally secure and performant Cosmos Hub in the years to come. Specifically, we suggest discussing and making alterations to the following parameters: • “slash_fraction_double_sign” , which determines the penalty for equivocating (double-signing two different state hashes at the same height and round). Currently this is set to `0.05`. We think that the initial choice was reasonably conservative (low)…

Excerpt (1197 of 4974 characters). Read the whole post on the forum ↗

First reaction is that these are great suggestions.

I like all your suggestions here

I agree with all except number 1, maybe “0.2” is too high, would see it as “0.1”
Why?= The state of cosmos delegation is relatively high, but only for the known Validators.
The event of increasing it to 20% will trigger a higher risk in the minds of delegators and even if we will have 150 validators cap, only the first 20% top validators will receive delegations and thus will have more power, meaning a more centralized approach rather than a decentralized one.

I like except for point 1 . We delegators are still experimenting with finding “honest” validators and this will make us more wary of going outside of the top 20 - 50 validators and using newcomers.
ATM we have no way of trusting newcomers , so little information about them or their setups.

BTW against increasing unbonding period … unless you do it over a percentage of holding over time. i.e. 1st 20% is 21 days , further 20% 30 days etc.
I would also like to see an unbonding option for say 7-10 days where you are penalised by losing rewards for x days.

Thank you for great suggestions! Chris, you never disappoint me. I will write down some of our opinions on each topic! • I think 20% is too high for current chain environment. Although some validators actively use KMS right now, still KMS is not a major adoption due to short period(1~2 months) of robustness proof. Also, cosmos-sdk is still in alpha phase without the core utility - IBC. Therefore, from both perspective, it is too early to decide 20%. Immature adoption of 20% double-signing slashing will harden the oligopoly of early bird validators, especially those from the Cosmos/Tendermint team. I insist to stay 5% until we have very stable 6 months evidence of KMS running on mainnet. • I agree on topic 2! We definitely need quicker response of inflation when sudden staking ratio drop happens. I actually want to suggest that the speed of inflation dynamic should hike more than linearly when staking ratio is under dangerous level(<40% for example). The model can be fixed so that the speed is related to “(current staking ratio - 67%)^n” where n is bigger than 1.0. Could you consider non-linear model please? • Currently we don’t see immediate necessity of increasing…

Excerpt (1196 of 1727 characters). Read the whole post on the forum ↗

Thanks for taking the time to bring these suggestions to the community. We have discussed them internally at validator.network and have the following comments. (1) We do not mind raising the double-signing slashing percantage, although 0.2 subjectively seems a bit aggressive. The penalty for double-signing is already high enough that avoiding it seems to be front-and-center for most validators, even to the detriment of uptime. We would prefer to see a focus on improving uptime for validators by tightening slashing conditions for missing blocks. By my back-of-the-napkin calculations and understanding of the slashing parameters, a validator can be down for nearly 9 hours without being penalized. (2) No comments regarding this point at the moment. (3) We believe it’s a bit early to expand the validator set significantly for the following reasons: (a) If someone is serious about starting a new validator, obtaining enough ATOMs to enter the top 100 is still manageable and definitely cheaper than the on-going cost of validator operations following best practices and recommended minimums. Expanding the validator set with “bedroom validators” doesn’t really add a lot of value…

Excerpt (1198 of 1919 characters). Read the whole post on the forum ↗

Some of our (Chorus One’s) thoughts on the proposal: • An increase in the slashing penalty for double-signing makes sense, but 20% feels like a bit too much. Something like 10% seems more reasonable. The network is still immature and the most likely reason for a double signing would be an accident, not intentional. 2. This makes perfect sense and the metric chosen is reasonable. 3. This is premature in our view. There are not 100 high quality validators at this point. Validators at at the end of the set have hardly any delegations so essentially no influence on the process. This will add communication overhead and increase block times with little added benefit, in our view. 4. Increasing the community tax also seems premature. Right now, there are no proposals for how to even access and deploy those funds. Let’s figure that out first before putting more capital in there. That should also be tested with small amounts first and the 0.02 are sufficient for that. Once that is working and tested, increasing the tax could definitely make sense. A few more things: • We would strongly urge you to make these as separate proposals so people can decide on each one…

Excerpt (1190 of 1703 characters). Read the whole post on the forum ↗

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)

Here are my views (syncnode validator) on the proposal: • 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. • Nothing to add to this point. It makes perfect sense from my point of view • 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. • 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…

Excerpt (1199 of 1262 characters). Read the whole post on the forum ↗

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: • 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) • 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). • 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…

Excerpt (1196 of 1390 characters). Read the whole post on the forum ↗

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.

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.

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

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)

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.

Hey @nodeateam & @UbikCapital - thanks for your feedback; just to clarify, the immediately proposed changes are only these: cwgoes: 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: • 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) • 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). • 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…

Excerpt (1199 of 1583 characters). Read the whole post on the forum ↗

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.

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

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)?

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

Probably, though still as separate parameter change proposals.

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

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?

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.

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…

Excerpt (1173 of 1557 characters). Read the whole post on the forum ↗

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!

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.