research/casper/README.md

2.4 KiB

The general idea of this implementation of Casper is as follows:

  1. There exists a deterministic algorithm which determines a single proposer for each block. Here, the algorithm is simple: every validator is assigned an ID in the range 0 <= i < NUM_VALIDATORS, and validator i proposes all blocks NUM_VALIDATORS * k + i for all k ϵ Z.
  2. Validators perform a binary repeated betting procedure on every height, where they bet a value 0 < p < 1 for the probability that they think that a block at that height will be finalized. The bets are incentivized via logarithmic scoring rule, and the result of the bets themselves determines finalization (ie. if 2/3 of all validators bet p > 0.9999, the block is considered finalized, and if 2/3 of all validators bet p < 0.0001, then the state of no block existing at that height is considered finalized); hence, the betting process is self-referential.
  3. From an incentive standpoint, each validator's optimal strategy is to bet the way they expect everyone else to be betting; hence, it is like a schellingcoin game in certain respects. Convergence in either direction is incentivized. As p approaches 0 or 1, the reward for betting correctly increases, but the penalty for betting incorrectly increases hyperbolically, so one only has the incentive to bet p > 0.9999 or p < 0.0001 if they are really sure that their bet is correct.
  4. If a validator's vote exceeds p = 0.9, they also need to supply the hash of the block header. Proposing two blocks at a given height is punishable by total deposit slashing.
  5. From a BFT theory standpoint, this algorithm can be combined with a default strategy where bets are recorded in log odds (ie. q = ln(p/(1-p))), if 2/3 of voters vote q = k or higher for k >= 1, you vote q = k+1, and if 2/3 of voters vote q = k or lower for k <= -1, you vote q = k-1; this is similar to a highly protracted ten-round version of Tendermint (log odds of p = 0.9999 ~= 9.21).
  6. If 2/3 of voters do not either vote q >= 1 or q <= -1, then the default strategy is to vote 0 if a block has not yet arrived and it may arrive close to the specified time, vote q = 1 if a block has arrived close to the specified time, and vote q = -1 if a block either has not arrived and the time is far beyond the specified time, or if a block has arrived and the time is far beyond the specified time. Hence, if a block at a particular height does not appear, the votes will converge toward 0.