(Almost) risk-free staking with slashing enabled

NEAR uses slashing for two kinds of misbehavior:

  1. Double signing
  2. Invalid state transition

The latter only makes sense when there’s more than one shard (or, more specifically, once we have scaled to an extent that most of the block producers cannot track most of the shards).

The slashing is disabled on the mainnet today.

The primary issue with slashing is that once slashing is enabled, way fewer people will be willing to stake or delegate (assuming delegators are also risking their funds in the event their validator is slashed). Thus, in this post I want to start a discussion of one approach how to significantly reduce the risk of getting slashed for misconfiguration (e.g. an incorrect failover resulting in a double sign), while keeping the security benefits of slashing.

The proposal

The proposal is the following: in the event that a validator is caught misbehaving (a cryptographic proof of a double sign or an invalid state transition is presented), their funds are not slashed, but rather they are locked on their account, and the validator is removed from the active set.

Then the validators in the next epoch vote on whether to release the funds, or burn them. The validators in the next epoch cannot withdraw their funds unless they have voted. Once the total number of votes reaches 2/3, the dominant vote is used: either the funds of the validator that misbehaved are released or they are burned.

Generally, an intentional misbehavior is obvious (e.g. if a single validator double signed, it’s almost certainly an accident, while if several validators double signed around the same time, it’s likely a collusion).

The issue I see with it is that validators have an incentive to slash the validator even if it’s clear that the misbehavior was an accident – after all, a validator being slashed burns quite a few tokens, and thus the price will go up. And the validators that vote have lots of NEAR as well, so the slight uptick in the price is quite noticeable for them.

However, I think the validators have a stronger incentive to vote properly, because a precedent of voting to burn the stake of a vaoidator that hasn’t intentionally committed a slashable behavior will likely result in similar outcomes in the future, and each validator operates under a risk of being on the other side of the vote in the future.

Curious about the opinions re: the proposal above, as well as other ideas how to make slashing detract fewer people from participation

6 Likes

Interesting idea. What would be quorum for such a vote? Wondering if this sort of thing could reduce the threshold for a byzantine attack.

Good point.

With double signing one would still have to get 2/3 of stake to actually create a fork.

But for invalid state transition indeed having just over 1/3 of stake might be enough to create an invalid state transition, and then not get slashed.

So a better way would be to require that one gets their funds released once 2/3 of stake voted to release the funds.

2 Likes

I like the idea. We do need to make sure that freezing funds (and slashing overall) works with staking pool contracts.

This definitely should require 2/3 of stake to vote. We also would need a good way to enforce timely vote.

Also implementation wise it might be easier to move funds into “vote for slashing” contract and then return if voted “yes” or leave / burn there.

2 Likes

Ensuring that enough validators vote at all, let alone in a timely manner, seems like the biggest issue to me. I’m not up to speed on Near devops–can a validator vote easily (ie. without having to use highly secured keys)? Can this sort of thing be integrated into existing alerts tooling?

I briefly mentioned the way to address enforcing to vote in the original post: I’m suggesting to disallow unstaking until the validator voted. It on itself doesn’t guarantee “timely” vote, an average validator can go for years without ever unstaking, but it does guarantee eventual vote.

As an alternative, we can also schedule any validator that hasn’t voted for kickout several epochs after the vote start, at which point they won’t be able to either unstake, or rejoin the active set, unless they have voted. This will also provide a timely vote.

3 Likes

Thanks, I missed that. Great idea, re: withholding rewards withdrawal–I like it because it’s more of a nudge than a push to vote.

Could this incentive mechanism lead to automated voting to default to either burn or release? I know automated voting is not in the long-term interest of the network and thus not good for validators, but in the short-term it reduces attentional resources, which is kind of the bottleneck for operators.

Like Docile Gavin would set things up so my validator periodically votes to release, assuming that 99.9% of the time equivocation is unintentional and that the network will be fine.

Do validators in the next epoch have to vote during that epoch?

1 Like

Not necessarily. The incentive to vote in a timely manner can have the number of epochs as a parameter. If one hasn’t voted in the allocated number of epochs, they get kicked out.

This technique can also be used for other kinds of votes in the governance process, not only for votes for funds release.

This is hard to fight against, and I can see this happening. Potentially some direction of thought here is to shuffle the options, so that 0 is not always to burn and 1 is not always to release, and have one extra option that if voted for immediately kicks the validator who voted for such an option out, to incentivize not voting randomly. (still gameable, given the vote is on chain, validators can go an extra mile and have a script that parses out the order, but that requires more effort than just configuring to always vote for zero)

1 Like

In this case I think that the balance is to make the consequences of not voting annoying enough to act, but inconsequential enough that nobody does the work to automate it.

I like the idea, except I don’t think the vote should be required by other validators. The locking mechanism of other validators may require changes to the staking pool contracts and may have negative side-effects.

Instead I’d recommend to increase the locking period of the slashed funds and make them automatically be released one the time passes. The other validators can still release or burn the slashed funds earlier.