On burning funds and rewarding slashers

[whyrusleeping]

There are three different places where a filecoin miner may be slashed:

• When submitting two blocks at the same height (consensus slashing)
• When failing to submit their PoST on time (storage fault slashing)
• When removing data before a deal expires (broken contract slashing)

In each of these scenarios, some funds are taken from the miner. The question now is what to do with those funds? We have two main options here, burn the funds (make them unspendable) and give the funds to the slasher, and the solution i think lies in picking the ratio of each to do. Some amount should be burned, and some amount should be given to the slasher.

Let's look at a couple potential proposals:

Burn all slashed funds

In this proposal, we burn all the funds that are being slashed. Now, the slasher must pay transaction fees to slash the offending party, and their only reward is that there are now slightly less total Filecoin in the network. The risk here is that the incentive to slash is so low, that people might never do it (the cost is higher than the benefit)

Give all slashed funds to the slasher

In this proposal, all of the slashed funds go to the slasher. This runs into two fairly subtle issues: For one, now if an attacker misbehaves, they can slash themselves with another identity to greatly mitigate the cost of their attack. Two, given a sufficient amount of funds being slashed, this can cause miners to try and fork in order to claim the slashing reward for themselves. This can cause instability in the chain, and weird incentives.

So, from these, we come up with some constraints:

• Slashers reward needs to be enough to incentivize people to actually slash
• Slashers rewards should not be so high as to incite forks between competing miners
• Amount burned should be enough that an attacker is sufficiently penalized, even if they slash themselves

[whyrusleeping]

The solution should reward the slasher an amount greater than a reasonable transaction fee for the slashing (requires knowledge of the costs of these calls) and is at most half of the total funds being penalized. A weird scenario comes up when the amount being penalized is less than (or near) the costs of invoking the slashing method. Some weird behavior may pop up in cases where network congestion causes fees to be very high.

[whyrusleeping]

cc @zixuanzh @decentralion and @nicola for discussion

[teamdandelion]

One idea that comes to mind is having the proportion of funds that go to the slasher start small (e.g. .1%) and then increase to 100% over the next several blocks. This has several features:

• It introduces price competition between slashers -- whichever slasher is willing to do it for the lowest "fee" will get the job. (Note that "burning FIL" is equivalent to "redistribute FIL to everyone else", so it makes sense to think of the network as offering this slashing job to the lowest bidder)
• It makes it infeasible for a miner to slash themself and recover more than a tiny fraction of their collateral
• In high fee situations or very small rewards, someone will still show up eventually, provided that the amount to be slashed is still greater than the tx fee
• It greatly mitigates the "forks competing for the slash reward" issue, because slashers will compete by accepting a lower price rather than playing a lottery where the lucky gets a giant payout. Theoretically, a slash could be so huge that it's worth fork-gaming to get 0.1% of it, but it seems much less likely.

The time period should still be pretty short (ie it should tend to 100% within a few hours at most) so that we don't have to worry about actors withdrawing the collateral before it gets slashed. So, a simple proposal could be to have p = max(0.001 * 1.26 ^ b, 1), where p is the proportional payout to the slasher, and b is the number of blocks since the misbehavior. This has the feature that the reward starts very small, and grows to 100% after 30 blocks.

[whyrusleeping]

@decentralion wow. I love this idea.

[zixuanzh]

@decentralion i really like this proposal as well. Great job! FWIW, it is essentially a variation of Dutch Auction (first-price auction). I did a quick derivation, given the following notations.

• R: total collateral in FIL to be slashed
• v_i: valuation of slasher reward for a slasher i in terms of percentage of R (minus transaction cost and other things for simplicity)
• b_i: bid of slasher reward from a slasher i in terms of percentage of R

A slasher i will win when b_i < min(b_j) for all b_j other than b_i and get a payout of

v_i * R - b_i * R

and a payout of 0 otherwise. I believe it can be proven that (N-1)/N * v_i + (N-1)/N is the Bayes-Nash Equilibrium strategy profile and I have a sketch proof on a piece of paper. What it is saying is that the more slashers we have, the more likely that slashers will bid according to their true valuation of the slasher reward, after taking transaction and other costs into account (these will affect the valuation). (b_1 = 1/2 * v_1 + 1/2, b_2 = 1/2 * v_2 + 1/2) is the equilibrium when there are only two bidders.

[zixuanzh]

This also has the nice general properties of a Dutch auction, it can happen pretty quickly (as fast as p is updated with minimal communication requirement between parties. We can do some tuning on fast p should grow.

@whyrusleeping I believe we should use the same mechanism for all slashing conditions. Do you foresee any reasons why we will have to modify it for different slashing conditions?

@decentralion my only concern with this is that it might be hard to tell how much slashers will value the slasher reward as a percentage and how long on average it will take for a slasher to slash ahead of time for us to do modeling/simulation on future FIL in circulation and other parameters. Perhaps we can just deal with this through simulated data.

[whyrusleeping]

@zixuanzh this seems like a pretty solid approach for all slashing conditions. The only tricky one would be for broken contract slashing, where the storage collateral should go back to the client, who might not necessarily be the slasher.

[teamdandelion]

@zixuanzh framing it as an auction suggests an interesting idea: that slashers can actually submit explicit bids, rather than implicitly setting the price based on how many blocks after the slashable event they wait before slashing. however, this would actually open the system to censorship attacks, where the miner producing the block simply censors all other slash requests other than their own. so having the price be naturally set by the # of blocks is actually a necessary feature.

@whyrusleeping it should generalize to that case as well. in that case, p goes to the slasher (where p is usually very small) and 1-p goes to the client, rather than being burned.

[zixuanzh]

@decentralion Just to clarify, in a Dutch auction, auction usually starts from a high price (similar to a small p in our case) and lowers it until some bidder is willing to accept it (increases p as the number of blocks increases). Submitting a bid in such an auction just means signaling to the auctioneer that the bidder is willing to accept the prevailing price. And the first bidder submitting the bid will be the one winning the auction.

Our current setup is strategically equivalent to a Dutch auction from a game theory perspective. This just means that even though the mechanisms may look different, the underlying incentive structures are the same. A bidder's decision is a trade-off between the probability of winning the auction and a higher payout (accepting a small p has a higher chance of winning but lowers the final payout). So I was formalizing your proposal with some auction theory and proof. The proof is similar to how Dutch auctions are strategically equivalent to first-price seal-bid auctions.

Regarding censorship attacks, just so that we are on the same page, it will not be possible in our setup because if block-producing miners want to censor other miners' slash requests, they will have to submit their own slash request in the current block and end up getting a smaller p. Otherwise, other miners' slash requests will be included by another block-producing miner in another block.

[teamdandelion]

Got it, thanks for the clarification @zixuanzh. I didn't know what a dutch auction is, but I thought I knew, which is a dangerous place to be in. I see now how they're equivalent.

Re censorship: Agreed that it's not possible in our current setup*, it would be possible in an alternative setup where the slashers post explicit bids to slash (and lowest bid gets it). That would have a slight advantage that it doesn't have the hardcoded price schedule (e.g. what if it turns out 0.1% is too high an initial fee), but the censorship attack makes it nonviable.

• Actually a censorship attack is still possible if a miner has reason to believe that they will mine the next block as well as this one. In that case, they can censor everyone who slashes in this block, and then censor everyone except themselves in the block after that. However, a miner that can reliably predict that they will win the next block is probably capable of more nefarious things, e.g. 51% attacks.

[zixuanzh]

@whyrusleeping just to be on the same page, regarding broken contract slashing, it will be storage collateral that gets slashed, not pledge collateral? If that is the case, we might want to design a different cap on p or some other mechanisms so that there is a meaningful amount of storage collateral that goes to users. It will be a different story if we are slashing on pledge collateral but storage collateral fully goes to users.

[teamdandelion]

we might want to design a different cap on p or some other mechanisms so that there is a meaningful amount of storage collateral that goes to users.

I don't see an issue. When slashing storage collateral, some fraction p goes to the slasher, and 1-p goes to the user whose contract defaulted. As with pledge collateral slashing, market dynamics should ensure that a very large fraction goes back to the affected user.

[pooja]

Needs to be documented in the spec

[pooja]

@decentralion Would you have some bandwidth to help document this in the spec?

[teamdandelion]

Yeah, I can help document this. @whyrusleeping can you point me to where this information should live in the spec?

[teamdandelion]

cc @zixuanzh who has written a design doc with the contents of this thread

[whyrusleeping]

@decentralion I think this will mostly just need to change the pseudocode for slashing in actors.md, in SlashConsensusFault and SlashStorageFault.

[anorth]

cc @zixuanzh who has written a design doc with the contents of this thread

@zixuanzh @decentralion could you please share this design doc? I am currently drafting the go-filecoin design doc for our implementation of faults and slashing.

[a2468834]

Sorry for asking questions in this closed issue, I cannot find the answer for weeks.😭

I still do not understand where do these 3 types of slashing fees go in the latest version of Filecoin consensus?

(1) Is it correct all 3 types of slashing fees were paid by miner and received by slasher? (2) Where (or which section) may I find in the spec.filecoin.io about these mechanism? (3) How can a Filecoin node become a slasher? (I guess just simply submitting fault proofs to Filecoin network?)

Thanks for anyone willing to answer my questions.🙏👍❤

[Stebalien]

(1) Is it correct all 3 types of slashing fees were paid by miner and received by slasher?

No. Most "slashing" events are performed by the chain itself. That is, normal execution of the chain will cause the system to notice that something isn't right and impose a penalty. In this case, the penalty is always burnt. That is, it is paid to a "burnt funds" account (the account has no key and funds deposited in this account can never be spent).

However, there are two cases where the system won't automatically notice that something went wrong:

1. The first case: When submitting two blocks at the same height (consensus slashing).
2. A new case: When a storage provider submits an invalid WindowedPoSt proof. See https://github.com/filecoin-project/FIPs/pull/59 for details.

In both of these cases, anyone can submit a proof of misbehavior to the chain. If submitter successfully proves misbehavior:

1. The submitter will be rewarded some amount of FIL.
2. The rest of the penalty will be burnt. It's important to always burn something to prevent storage providers from misbehaving then self-reporting their misbehavior to avoid getting penalized.

---

1. Consensus fault slashing is described here: https://spec.filecoin.io/#section-glossary.consensus-fault-slashing. The relevant code is in https://github.com/filecoin-project/specs-actors/blob/c3afe7fa3c5c2f220eb0c590b5d3ed64b5762dda/actors/builtin/miner/miner_actor.go#L1925.
2. The code that handles window post disputes can be found in https://github.com/filecoin-project/specs-actors/blob/c3afe7fa3c5c2f220eb0c590b5d3ed64b5762dda/actors/builtin/miner/miner_actor.go#L488. A reference implementation of a disputer can be found in https://github.com/filecoin-project/lotus/blob/26ae8bb3a76c0cf7a4bdb187e586cd30213c67ed/cli/disputer.go#L20.

To answer your final question, yes, anyone can become a slasher. The main issue you'll run into is front-running: others on the network can see your messages and try to "race" you to steal the reward.

[a2468834]

Thanks for replying me.

After reading pages, I can finally figure out how do shashing events work. But, I still have a minor question I would like to ask. 🥲

There are 2 faults would cause penalties, storage fault and consensus fault. Assume malicious miners don't submit any sector recovery records after they do some bad things.

• Storage fault (SF) will force malicious miners need to pay ( Fault Fee + Sector Penalty + Termination Penalty ).
• Consensus fault (CF) will force they need to pay consensus fault penalty (CFP).

According to your great explanation and those links, I have known that part of CFP will go to slasher as rewards and rest of them will be burnt.

---

Therefore, my question is: Is it correct that the whole SF will be burnt? I used to misunderstand SF and miner collateral would give to the deal's StorageClient as compensations for losing their data.

I truly appreciate your detailed descriptions and links to source codes, it really help me a lot.🙏

[Stebalien]

Is it correct that the whole SF will be burnt?

Yes. The client will be refunded the remainder of their payments and their collateral, but nothing more. Unfortunately, SF can't be refunded to the client otherwise the storage provider would be able to "self deal" (make deals with themselves) to recoup their losses on fault. Really, SF is paying the network for failing to perform a service to the network.