There are four cases when the Livepeer protocol will slash participants (take some of their bonded token away) for violating the rules/requirements of participating in the protocol. Here is a summary of these conditions during the upcoming testnet soft launch. Please share feedback here or in our new protocol chat room.
1) A transcoder fails a segment verification
This occurs when the protocol is verifying that the work that a transcoder did on a segment of video was performed correctly. The protocol can automatically detect this failure and can slash the transcoder accordingly.
2) A transcoder fails to invoke verification on a segment they were required to verify
After a transcoder commits to all the work they did on a stream, the protocol determines which segments, if any, need to be verified. If the transcoder doesn’t invoke verification on the required segments, they can be slashed. This can not be detected automatically, and instead requires a checker to invoke a transaction that slashes the transcoder during the slash period. The checker can earn a reward (portion of the slashed fees for doing so).
3) A transcoder doesn’t call the Reward() function to distribute block rewards to delegators
We have decided not to slash in this case. The lost block reward is enough of a penalty and enough of an incentive to get delegators to choose another transcoder who will not fail to invoke Reward().
4) A transcoder doesn’t do enough work
Transcoders are expected to be available to perform jobs assigned to them, and be priced competitively enough to match demand from broadcasters. The amount of work they’re expected to perform is relative to the total stake delegated towards them. The protocol will have a parameter that defines a % threshold that a transcoder needs to come within of that expectation, for example 25%. At round N+2, a checker can check to make sure that a transcoder with 10% stake passed at least 2.5% of verifications (25% of 10%) in round N, and if not, then they can invoke a slash on that transcoder.
When transcoders are slashed in any of these scenarios they are immediately inactivated, so they will not be slashed further, but they will also forgo block rewards and fees. This gives delegates a chance to unbond or delegate towards a more reliable transcoder.
It’s debatable in which cases a transcoders delegates should also be slashed. For the testnet soft launch we will likely start out without delegate slashing.
Logic for when checker should perform checks and submit slash transactions is also an open question. If the client software does this automatically for every user, then the network will be flooded with transactions which will all fail except for the first. We have some ideas about how to limit this down the line. During the testnet soft launch we’ll likely automatically invoke slash transactions for any client who starts with the --checker option.