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) due to the comparatively higher likelihood of software bugs or misconfigurations relative to intentional Byzantine behaviour, but that this value will need to increase over time to provide a higher degree of economic security to the Hub. Provisionally, we suggest increasing this parameter to 0.2 (resulting in a 20% slashing rate).
First-order effects of an increase will be an increased cost of bribery attacks and increased supply deflation due to burned tokens should a slash occur. Second-order effects may include an increased focus on validator security by rational delegators (we think this will be generally beneficial) and an increased reluctance to delegate due to the higher risk (potentially problematic, but see the next suggestion).
“inflation_rate_change”, which determines the maximum rate of change in the inflation rate (second derivative of inflation). The Cosmos Hub dynamically targets a 2/3 bonded ratio, adjusting the inflation rate between minimum and maximum bounds (currently 0.07 and 0.20) to discover which inflation rate is necessary to reach that ratio (for a longer explanation, see here). Currently, this is set to 0.13, meaning that it will take a year for the Cosmos Hub to reach 20% inflation (if the bonded stake remains below 2/3). Provisionally, we suggest increasing this parameter to 0.52 (by a factor of four), which will enable the inflation rate to range between the minimum and the maximum in a period of three months. We think this will enable quicker reactions by the Hub to maintaining security in the face of changing external economic conditions (e.g. the price of Atom tokens), and we think information about the effects of differing inflation rates on user behaviour would be helpful to discover in the near term.
“max_validators”, which determines the maximum number of validators who can participate in consensus, currently 100. Provisionally, we suggest increasing this to 150. Tendermint can handle several hundred validators without substantial slowdowns (as demonstrated in Game of Stakes), so we think this increase is conservative, and it will allow more operators to join the Cosmos Hub and experiment with validation. We think this change alone is unlikely to result in meaningfully more decentralization of voting power and other changes will be required to acheive that (perhaps slashing incentive alterations), but if such changes are made the validator cap may then be the bottleneck on decentralization.
“community_tax”, which determines the fraction of inflation & fees sent to the community pool, designed to fund public goods (although it has not yet been put into use). Provisionally, we suggest increasing this to 0.1 and adding a simple proposal type for governance to spend funds from the community pool to an arbitrary Cosmos Hub address. Although the community pool has yet to be demonstrated and numerous operational challenges remain to be solved, we think public goods such as zone development, software upgrades for the Hub itself, higher-level tooling and application development, protocol & cryptography research, etc. will make or break the Cosmos Network and we should spend corresponding amounts of effort & funding on them.
We also expect that it may make sense to increase the unbonding period in the future, but we think it is not necessary to do so right now.
We will make a proposal (or several proposals) to include constant changes in the next hard fork (none of these require any software development effort, except possibly the proposal to spend from the community pool, which we are willing to implement), but no numbers are finalized and we would like to hear arguments from any and all sides first. Let the floor be open for discussion!
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 validator number from 100 to 150. I think we can agree on starting to discuss on increasing validator number when certain condition meets(when 100th validator has more than 1,000 ATOM power, for example)
I think raising community tax rate to 10% is a good purpose. But before this, I want to ask ICF to donate additional 20%(total 30% including tax, to-be) of their interest return to the community fund as a role model. Then, most delegators will be very HAPPY to donate more of their interest rewards to the community fund.
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 to the network as we see it.
(b) Looking at the list of validators outside the validator set (https://cosmos.bigdipper.live/validators/inactive) doesn’t suggest that there is a long line of highly qualified validators eager to join and support the network.
If someone is sufficiently serious about becoming a validator, the obstacles to doing it are still very surmountable, either by purchasing ATOMs for self-bonding or finding a “sponsor”-delegator among existing ATOM holders.
(4) In our view, it’s a bit too early to increase this parameter so drastically. We would like to first see an example of at least one case of the community fund being put to use, in order to observe how the entire process unfolds.
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 individually. Bundling these in one proposal doesn’t make sense.
Another parameter that should be changed in our view is downtime slashing. Right now, the barrier for that is ridiculously low. i.e. you can be down for many, many hours without punishment. This should be made much more strict. For example, it could be that if a validator is down more than 20% in a 24h window, they get slashed. (Which after all is a very minor penalty since they can just join the active set again and don’t lose delegators.)
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 need separate proposals.
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 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.
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.
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)
For slash_fraction_double_sign, 20% slashing rate is too high. Such a high slashing rate could have a big impact on small validators.
For “inflation_rate_change”. Let’s see some calculations before taking some decision.
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.
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.
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.
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)?
