This proposal is a work in progress.
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.
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 100 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 10,000th 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.
Transactions are signed to a particular validator. Half of the transaction fees from processed transactions are credited to the creator of the block in a "rewards map" in the proof of stake contract, and the other half is burned. The "rewards map" consists of n key-value pairs where the key is the bonded validator and the value is their corresponding accumulated share of transaction fees, denominated in REVs.
Every 10,000 blocks, all validators are taxed 100 REV from their slot in the rewards map.
Unbonding requests are submitted to the network through transactions (deploys). Unbonding requests accumulate in a "unbonding set" in the proof of stake contract. Every 10,000th block, one validator is stake-weight-randomly selected from the unbonding set. The selected validator is removed from both the bonds map and the rewards map. The sum of the corresponding REV values in both maps are inserted into a "withdrawal map" under the validator's public key. 50,000 blocks after the insertion of an entry into the withdrawal map, validators may withdraw the corresponding number of REVs in the withdrawal map to their own wallets.
Validators can propose non-empty blocks.
Proofs for slashing are submitted to the network through transactions (deploys). If the slashing attempt is valid, the validator's stake in the bonds map is set to 0 and an unbonding request is automatically inserted into the "unbonding set" to eventually remove the slashed validator. The slashed amount of REV is transferred from the proof of stake contract to the cooperative's wallet.
Attacks considered
"Block spamming by colluding validators": We can prevent validators from ignoring all "outside" transactions and building up a long chain with cheap to process "garbage" transactions to harvest block rewards by burning half of their transaction fees.
"Validator rotation slowing consensus": By having validator rotation only happen every 10,000 blocks, we lower the overhead of validator rotation.
"Risk of lost funds from validation bug": All slashed funds will go to the cooperative's wallet for starters, and the funds will be burned upon confirmation that the slash wasn't a validation bug.
"Not enough at stake validating": Only one validator can unbond every 10,000 blocks.
"Long range attack": We keep bonds locked for 50,000 blocks before allowing a withdraw of REVs (stake and transaction fee rewards).
"Validator weeding": There is no way to kick a validator out except by providing proofs for slashing. 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": By signing transactions to a specific validator, validators aren't able to steal transactions from each other.
"Lazy validator": By having a carrying cost of stake, validators who aren't able to produce blocks will want to leave the validating pool.
"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": It is possible to have the same 100 validators forever control the chain - oh well.
"Not having idle hardware": By having a bonding staging set, it allows time for validators to purchase/ready hardware for validating.