Validator Incentives and Casper

Definitions

Types of nodes and states a node can be in

Other terms related to the validation protocol

Constants used in the validation protocol

Protocol Proposal

The proof of stake (PoS) contract is a genesis contract written in Rholang. It defines a set of methods that codify how validator incentives will work.

Validators can propose non-empty blocks that have a maximum of MAX_SIZE size at any time they wish.

The active set of validators are defined in the "bonds map" of the proof of stake (PoS) contract. The bonds map consists of up to ACTIVE_VALIDATORS key-value pairs where the key is a validator's public key and the value is their corresponding stake, denominated in REVs.

Bonding requests, which are calls to the "bond" method in the PoS contract, are submitted through transactions to the network. Bonding requests insert the validator that initiated the transaction along with their stake into a "draw map" which has the same structure as the bonds map but is unlimited in size. Every EPOCHth block, as many requests are stake-weight-randomly selected from the draw map to fill up the bonds map. If the bonds map is currently full, then 10% of the bonds map is swapped out with the draw map using a random seed in the block.

There are no joining fees.

Transaction fees from processed transactions are split stake-weighted to the "rewards map" in the proof of stake contract. The "rewards map" is similar in structure to the "draw map", but instead of holding stakes, the rewards map holds the accumulated share of transaction fees, denominated in REVs.

Every SENIORAGE blocks, SENIORAGE_REWARD_PERCENT% of each validator's stake will be transferred from the coop's wallet to the corresponding validator's slot in the rewards map.

Unbonding requests, which are calls to the "unbond" method in the PoS contract, are submitted through transactions to the network. The validator corresponding to the deployer of the unbonding request is removed from both the bonds map and the rewards map. If a validator doesn't have a block in the past FORCED_UNBONDING_THRESHOLD blocks in current chain, any user may submit a transaction to forcefully unbond them. The sum of the corresponding REV values in both maps are inserted into a "withdrawal map" under the validator's public key. LONG_RANGE_ATTACK blocks after the insertion of an entry into the withdrawal map, validators are sent their corresponding number of REVs in the withdrawal map to their own wallets.

Slashing invalid blocks or equivocations is done through transactions that call the "slash" method in the PoS contract. If the slashing attempt is valid, the validator's stake in the bonds map is set to 0.

Attacks considered

"Block spamming by colluding validators": No protections as of now.

"Validator rotation slowing consensus": By having validator rotation only happen every EPOCH blocks, we lower the overhead of validator rotation.

"Risk of lost funds from software bug": The coop will have a policy to refund lost REVs that are from software bugs.

"Not enough at stake validating": No protections as of now.

"Long range attack": We keep bonds locked for 50,000 blocks before allowing a withdraw of REVs (stake and transaction fee rewards).

"Validator weeding": Validators will probably choose to leave voluntarily if they aren't able to gather enough transaction fees to offset the carrying cost of the stake.

"Inter-validator transaction stealing": As transaction fees are split stake-weighted, validators have no incentive to steal transactions from each other.

"Lazy validator": Validators who aren't able to produce blocks will be forcefully unbonded by other users.

"Partial slashing": By splitting the bonds map and the rewards map, we leave a path forward to implement partial slashing.

"Censoring senior validators": By having no joining fees, validators no longer have incentives to collude and censor other validators that are above them in seniority.

"Preventing long-term oligopoly": We automatically rotate the set of active validators.

"Not having idle hardware": By having an unlimited draw set, hardware owners always have a chance of validating.