(Proposal) Slashing rate reduction for downtime

Hi all,

Following up on this poll in the Mainnet-Validators channel a discussion around the current slashing rate of 1% being too high, as currently if a validator misses more than 2500 of 5000 blocks, the validator is taken out of the active set and penalized with a 1% of the stake, which includes the delegator stakes on that validator.

With 1% being a big percentage slash compared to other chains like Cosmos where the slashing rate is only 0.01% percent at the moment.

With the Infrastructure Committee meeting and the weekly Governance call, a lot of Committee concerns were addressed and reasons put forward for the reduction of the slashing rate or taking out the slashing rate altogether.

Some of the concerns to reduce but having a respectable penalty:

  • Security and stability of the network @the-dusky mentioned on the chat channel. This means the network is very less likely to get compromised when nodes go down.
  • A bad party on the network does not get penalized. A bad validator can continue to be on the network and cause instability without getting penalized, even after several disconnects and down-network or a great number of missed blocks.

Some arguments put forward to reduce or remove the slashing of funds altogether:

  • @moonstash talks about the barrier of entry to the Secret Network when Secret Contracts goes live is already going to higher compared to other networks like Cosmos. With estimates a couple of thousands of USD to get working (SGX-enabled) hardware, for the network. Having a low slashing rate will incentivize small validators to continue to be on the network. Also with validators already spending big sums of money to secure the network, they would work even harder to keep uptime in order to not miss block rewards, rather than worry about penalization.

  • I also talk about how this would enable decentralization as we can promote reliable home/office setups. Rather than centralized setups from data centers or cloud providers.

  • This will not only benefit Validators but also delegators can delegate to small validators with little to no risk providing more stake spread across delegators.

This proposal will keep the active Double-Sign Penalty at 5% as that only shows the careless execution by a Validator as mentioned in Governance call.

Currently, the numbers that have the greatest percentage of votes segregated from Chat and Call Polls are listed in the poll below. We want to hear more from the wider community and see if this is a supported argument. Please share your thoughts with the % of the slash you agree with and cast a vote in the poll below.

  • 0%
  • 0.01%
  • 0.1%
  • 0.25%

0 voters

If we see a large percentage of agreed number we would like to move this to a on-chain proposal. If you disagree please comment and share your concerns!!

1 Like

I just wanted to add my thoughts here. From my perspective every network with slashing for downtime is mostly following in the footsteps of cosmos yet the initial assumptions cosmos used to make the decision for slashing for downtime doesn’t seem to hold up. My understanding is the initial fear was pos wouldn’t work because nodes would go down too often.

As it stands no one has provided proof or data to suggest its good to have slashing for downtime whereas we know from the comments of small validators that slashing for downtime is a deterrent to their operations.

In my opinion slashing for downtime should be set to 0% so we can level the playing field a bit. This makes small operations more feasible and removes the incentive to delegate only to large professional operators. I am deeply opposed to arbitrary technical barriers that merely keep the largest nodes in power. People should delegate to a node because they agree with the ethos of the operator, not because the operator was slashed for downtime and they lost money.

2 Likes

The one thing that I am curious about with this is an attack scenario. The big issue right now for validators is the cost of 3 separate SGX machines to create a so called sentry node. The main purpose of this is not to protect downtime from faulty setup or bad hardware, but from DDoS attacks. With 0 slashing, do we risk too many validators opting for a single machine setup and then open the system to a coordinated attack scenario.
There are a ton of assumptions and questions imbedded in this comment. Does downtime itself dis-incentivize single machine setups without slashing? Is the risk really that great on a system wide basis? Would increased jail-time be a better less punitive option? I don’t know the answers to these and other questions, but I think it should be considered.
The really encouraging thing that happened today was that we got direct feedback from an authoritative source. I would just like to make sure edge cases are asked about.

1 Like

Hey yes, thanks to Zaki Manian!

Does downtime itself dis-incentivize single machine setups without slashing?

Another thing about Sentry setup, like you mentioned is for DDOS. And I have bought this up before, but we don’t have to go to Sentry Architecture for DDOS.
There are many ways to protect DDOS attacks and that can be expensive or cheaper depending on your setup.

Hence it’s not single machine setups that need to be dis-incentivised but making sure that you have reliable uptime on the network to earn block-rewards and let your delegators earn them as well.

Again increasing jail-time can be implemented on this if we notice that there is Malpractice on the network.

To expand on what @mohammedpatla said.

Sentry node architecture has many different implementations. It doesn’t have to be configured as described in official docs to have the same effect. That is just one overview of how to achieve ddos protection.

In regards to extending jailing time. I wonder if that should be involved in this proposal. I’d like to limit scope and visit that if someone has some really strong feelings. However I do think lowering the 4 hour window for downtime would be a mistake especially in regards to small operators. If anything I would support extending it to something like 8 hours. Not sure on length of jail time.

1 Like

Agreed that generally reducing the slashing rate is a good thing. I don’t think 0% is the right approach, as we need some balance between how much we’re incentivizing nodes for staying online vs how deterring the penalty is for smaller validators.

All in all, I think 0.01%-0.1% is the right range.

This is the danger with polls like this, I already know the poll result: everyone will choose the smallest %, its just basic behaviour theory. People dont want to lose their coins, I mean who does, but a lot of people are going to take this poll and are going to vote on their stake without knowing the future repercussions. Its always “now” they want more coins “now”

So, I think people need to be more informed and been given as much information as possible to the worst thing that could happen and the risks involved. We could even pose the question a little bit better: How much chance are you willing to take that the node penalized for downtime is always going to be a good actor to risk the network and the value of your coin?

But if we just ask: how much money do you want us to take away from you? The answer to that question would be: As little as possible. It just becomes a formality at this point.

Hey,

Thanks for sharing your concern.
Unfortunately, there is no way to gather an informal yes/no outside of on-chain without getting a Poll Result.

As far as concerns about how much money/coins you would loose, from a psychological perspective, yes it has to be less money spent. But then again if you think about it, its just a carrot and stick approach to this situation.

But even after taking out the penalty that can also be taken as an incentive for Validators to keep uptime. Like mentioned, losing block rewards is already a concern for Validators, with expensive equipment and maintenance cost, commissions are very important, and for every block missed you are losing $$ to continue running on the network.

Again, in my opinion, considering the network health, we have not noticed any issues if one operator drops off the network. The concern more lies about when several nodes drop off the network. So I don’t know why someone should be penalized for this reason.

Again this particular change is for the immediate network requirement, to provide more incentive for validators to join the network.

I’d like to see more than words in regards to your statement 0% slashing or some other low number is bad. As it stands no one has provided any meaningful data, just opinions and anecdotal commentary.

I can’t speak for others but I personally can be swayed by good data, less so swayed by opinion.

What’s the timeline you’re thinking for a proposal @moonstash ? I could see adjusting the slashing rate ASAP to be 0.01% (the current poll leader) and to bring it in line with the Cosmos ecosystem, then opening a discussion post secret contracts about whether it should be eliminated entirely (based on the thoughts Zaki recently expressed on the gov call).

2 Likes

I’d support putting out a proposal today or tomorrow for 0.01%

1 Like

On Aug 7th 2020 the “Modification to Downtime Slashing” proposal was submitted. This is being proposed to encourage the further decentralization of stake and to bring the slashing rate to a more reasonable level for all. This will be the first proposal for stakeholders to vote on since secret became more accessible through the burn. The first phase will be the deposit phase, for a period of 7 days people will be able to deposit an amount of secret into the proposal showing their support. Once 1000 SCRT is deposited the proposal will move into the voting period which will last 7 days. Anyone with SCRT will be able to contribute to the deposit or vote using ledger, mathwallet, or keplr directly on Puzzle. Once the proposal reaches a quorum (33.4% of online voting power votes on the proposal) then the proposal will be considered valid and the deposits will refund after the voting period ends.

You can inspect the on chain details of the proposal here.

https://puzzle.report/secret/chains/secret-1/governance/proposals/17

1 Like

Figured I’d make an account in the forums after being in one of the telegram chats for a while now.

Personally, I’m in favor of getting rid of the downtime slashing and reassessing in the future once the network gains popularity. Right now we’re at a very early phase and the the barriers to entry are already higher than usual by the hardware requirements, so 1% slashing on top of the hardware requirements does feel a bit strict.

At the same time, being such a small community also means that the degree of enthusiasts is significantly higher proportionally. I could be wrong, but I think this means that the infrastructure in place most validators have is of high quality already (Why would an enthusiast run a shit-tier validator? I mean, you never know, but I wouldn’t bet too high on it), so I don’t think that by lowering the downtime we’re compromising the quality of the network.

Additionally, it is already in a delegators best interest to choose the best node possible,
really. So why would delegators stay on a node that constantly keeps going down? Eventually people would get tired and move on to other, high-quality nodes, regardless of slashing or not. Downtime already = less rewards.

I think market forces on their own force out bad validators out of the network, so downtime slashing feels like it would only penalize accidents rather than laziness.

Another alternative maybe worth exploring would be to extend the window before slashing occurs. 4 hours (i think it is?) before losing 1% feels rough. 48-72 hours before losing 1%? Less so. 4 hours is definitely within the realm of I was at work and didn’t notice, whereas the latter approaches idgaf territory.

In any case, it’s worth remembering that we don’t have to set this in stone right now, and we can always reassess in the future when we have more actors in play.

3 Likes

I agree with Ian. Especially in the beginning, we need to lower the barrier of entry to allow for a healthy decentralization. Furthermore, positive reinforcement for good behavior has been shown to be superior to punishment for accidental/careless behavior when attempting to modify behavior. When it comes to
Malicious behavior, I do agree with a 5% slashing. There is research to support both of these claims.

As our network develops, I still stand by my recommendation from 1 year ago, to incentivize good behavior and by implementing a node reputation score (Similar to karma on Reddit). This type of reward for good bahavior puts social pressure on node operators and will be beneficial for the health of the network.

2 Likes

I doubt you will find any data. All of this is novelty. My point was if you read it, had less to do with whats effective or not, but more to do with informing the voters in both sides of the arguments and posing a neutral question, otherwise you are really just telling people what to do.