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.


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.

| improve this answer | |
  • Which implementation are you referring to? Give us a link. – James Ray Jun 21 '18 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 Jun 21 '18 at 4:53
  • I should have said proposed implementation by the Rchain Casper team. There is no formal spec yet. – Kent Shikama Jun 21 '18 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. – Kent Shikama Jun 21 '18 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 . – Kent Shikama Jun 22 '18 at 3:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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