While reading through the Nothing at Stake section of the Proof of Stake FAQs it is described how dishonest validators will be punished for voting on two chains. This requires a proof of misbehavior which will have to be inserted in the chain by another honest validator.

This makes me wonder:

  • what is the incentive for validators to submit this proof, given that it takes resources to monitor for these kinds of misbehavior?
  • if there is an incentive, why would a validator include anyone's proof if they can simply replace it with their own proof to get this incentive?

with sharding this problem seems even worse, with a larger number of chains/shards to monitor.

1 Answer 1


I'm basing this answer on a particular implementation of PoS that is based on Vlad's Cbc-casper paper. The exact PoS implementation that Ethereum decides to implement may be different.

Let "validators" be entities that are responsible for creating blocks that have bonded stakes in the proof of stake contract. Only validators can create new blocks and only validators can slash other validators. Creating a new block on top of a invalid block is a slashable offence. The slashed bonded stake gets evenly distributed among all the remaining validators.

In other words, the incentive for the validators to validate blocks is to not accidentally build on top of an invalid block and get slashed themselves. Additionally, it doesn't matter which validator does the initial slashing as all proper (not faulty) validators will be rewarded.

Note by "building on top of", more pedantically, I refer to including the block in your block's justification - which is more inclusive than just using that block as your block's parent.

  • Which implementation are you referring to? Give us a link.
    – James Ray
    Commented Jun 21, 2018 at 2:57
  • "The slashed bonded stake gets evenly distributed among all the remaining validators." I think the trend is to burn slashed deposits.Distributing it evenly to all validators would add overhead.
    – James Ray
    Commented Jun 21, 2018 at 4:53
  • I should have said proposed implementation by the Rchain Casper team. There is no formal spec yet. Commented Jun 21, 2018 at 8:28
  • I see and that makes sense. I don't think the overhead is that great but it definitely doesn't beat burning. It also is more user friendly as opposed to validator friendly. Commented Jun 21, 2018 at 8:31
  • 1
    There is an enforced partial ordering; specifically, there is an ordering on names that have races. Transactions will have millisecond timestamps instead of sequential nonces. That architecture doc is fairly outdated. There is a forum for Rchain questions at forum.rchain.coop . Commented Jun 22, 2018 at 3:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.