Proof of Stake contract specification

NOTE: this is work in progress

Overview

todo

PoS parameters

active validators count: maximum number of active validators 

minimum/maximum bond: todo

epoch length: the length of the epoch specified in number of blocks 

quarantine time: number of epochs that a validator must spend in quarantine before receiving his stake&rewards

random commit duration: the duration in blocks of the random number commit phase


Bonding

todo

Unbonding

todo

Block creation process

Payments

Closing the block

Validator swapping

Motivation

We have the need to keep at most N validators active at some point (TODO: link to explanation here). On the other hand we want as many validators to participate. Because of this, we allow any validators to bond but we swap them periodically.

Validation epochs

The time is split in "epochs". During an epoch the set of active validators doesn't change. Each epoch has a fixed length in blocks. 

The PoS contract is responsible for changing the epoch. When its "closeBlock" method is called, it checks if the number of blocks is a multiple of the epoch length. If that is the case an epoch change will happen.

During the epoch change the following will happen:

  1. the withdrawing validators are removed from the active set of validators
  2. the rewards accumulated during the epoch are distributed to the active validators
  3. a given percentage of active validators are swapped randomly with inactive ones
  4. the validators who finished their quarantine time will received their stakes back and will be paid the rewards for their validation work

Validators selection

At each epoch change a percentage of the active validators will be randomly replaced with inactive ones. This random process must not be controlled by any validator, otherwise he will be able to select himself in the next epoch.

Also the validators must not be able to see the decision and build on the blocks that favour them.

For the above reasons the selection process is based on a commit/reveal mechanism.

Commit phase

In this phase each validator generates a random number R and sends a hash Hash(R) to the PoS contract which will store it.

Multiple commits from the same validator will fail. Only the first will succeed.

The commit phase will end after a given number of blocks. 

Reveal phase

This phase runs right after the commit phase has finished. During this phase the validators reveal their random number that match the previously committed image.

Any calls to PoS.revealRandom that happen before the  reveal phase will fail.

Any reveal without a commit will also fail.

Any validator which did not participate in the random commit/reveal protocol will not be rewarded at the end of the epoch.

Pay for execution

For each block the REV charged for execution of the contracts is stored in a vault controlled by the PoS contract.

TODO details

Reward distribution

At the end of the epoch, the rewards are distributed among the active validators who participated in the random commit/reveal protocol. The reward distribution is proportional to the validator stake.

The validators who haven't committed a random number will not be paid.