Decide on slashing requirements from the economic, security, and UX trade-offs around slashing or no-slashing staking protocols

[nathan-at-least]

Question

There is contention between slashing and constraining the downside for delegating stake in UX, economic, and security considerations. We need to decide along this trade-off spectrum.

Here we discuss only slashing or no-slashing, but many (but not all) of the trade-offs scale with the degree of slashing. For example, the qualitative difference between no slashing and a tiny amount of slashing might mean that some users are "turned off" by slashing (even a tiny amount) especially when they weren't aware of the slashing risk. OTOH, the direct financial harm to slashed users is very different for small vs large slashing. So some of the differences are qualitative around "0" or "not 0" and others are quantitative based on the scale of slashing risk.

Roles / Terminology

This ticket says "delegator" and "user" interchangeably. We assume most delegators are ill-informed, in that they are unlikely to understand slashing risks very well, and are unlikely to be able to distinguish validators very well or assess their performance.

This ticket uses "validators" for the node operators who contribute directly to block consensus. We assume all stake is in the form of delegations (so validators can/will self-delegate), and that validators take an operational fee from staking rewards, then all remaining rewards are distributed to delegations.

With Slashing

Pros

UX

• With slashing, users need to carefully consider delegations and which validators to delegate to.
  • This could stimulate more validator<->delegator relationship building across the ecosystem, and incentivize more proactive competition and good behavior among validators (or at least validators with better marketing). (Risks: some validators may become winners-take-all due to reputation/network effect and then they may behave maliciously to some degree while relying on their sticky reputation.)
  • By placing this responsibility on users, this may stimulate some proportion of users to become more engaged. (Risk: this may discourage another proportion of users to disengage.)

Econ/Security

• With slashing, validator incentives are well aligned with a smaller reward, because the opportunity cost for misbehavior is larger than the reward. Thus, a protocol with slashing can have a lower rate of dilution for the same amount of security vs a protocol without slashing.
• With slashing, attackers lose real value in (detected slashable) attacks, so this limits their capacity for attack. e.g. without slashing the opportunity cost is only foregone gains, so many different or repeated attacks are feasible whereas with slashing, every attack has a potential real cost, so too many failed attacks will deplete the attacker's capital.
• With a larger downside risk, less ZEC may be ultimately staked, which increases the returns for staking ZEC.

Cons

UX

• By placing a larger burden on users to select validators, this introduces a large hurdle to participation. How can delegators discover potential validators? How can they assess their trustworthiness? In-so-far as validators can game information asymmetry they can abuse delegator ignorance to either behave maliciously (with lessened consequences) or accrue larger-than-deserved network effect (thus centralization).
• Delegators who get slashed may lose faith in the protocol, especially for those ill-informed delegators who weren't anticipating slashing risk.

Econ/Security

• With a larger downside, less ZEC may be ultimately staked, which may result in lower network security. (Is this true? How much is this offset by the validator incentive alignment due to slashing opportunity cost?)
• Less ZEC staked and more risk may mean fewer validators, thus more centralization.

No-Slashing

Pros

UX

• If there's no slashing, the risk to delegating stake is low (only opportunity cost of that capital), so ill-informed users should be ok. With slashing, a delegating user may lose funds. If we assume a large proportion of users are ill-informed and cannot understand slashing risk, then in the no-slashing protocol, no users are unexpectedly harmed, whereas with the slashing protocol some fraction of users are unexpectedly harmed (which may also sour them against Zcash).
• With low risk of delegation, selecting a validator is less important for an individual user, and validator selection could potentially be automated, simplifying the cognitive burden of delegating, making it much easier for users to participate.

Econ/Security

• With no slashing risk, better-informed users are more likely to delegate more, increasing the overall ZEC at stake. (Same question as above about how this is counterbalanced with attacker opportunity costs being lower without slashing.)
• With no slashing risk, more validators may participate, potentially increasing decentralization.

Cons

UX

• Because delegators care less about which validator to delegate to, there is less of a relationship. Validators are less proactive in marketing or accruing users.

Econ/Security

• Because the opportunity cost is only determined by the staking rewards, larger staking rewards are needed for the same amount of security, thus the overall dilution rate is greater for the same amount of security.

[daira]

For example, the qualitative difference between no slashing and a tiny amount of slashing might mean that some users are "turned off" by slashing (even a tiny amount) especially when they weren't aware of the slashing risk.

It's possible to design the delegation protocol so that your vote for a proposal requires a signature from both you and the party you're delegating to. In which case the risk of slashing only applies in cases where both you and that party vote in a way that causes slashing (e.g. double-voting).

A disadvantage of this approach is that the latency of voting (and therefore of obtaining a two-thirds absolute supermajority for a proposal) may be higher.