This proposal is a work in progress.
Protocol Proposal
The current set of validators are defined in the "bonds map" of the proof of stake. The bonds map consists of n key-value pairs where the key is the bonded validator and the value is their corresponding stakes, denominated in REVs. The bonds map is sorted by the base 16 encoding of the public key of the validator and has a maximum of 100 entries (validators).
Validators can propose blocks at any time they want given that the block contains at least 100 REVs worth of transaction fees and 10,000 gas worth of execution. ADD: describe how the Coop sets and can change these values in the Casper values contract.
Bonding requests are submitted to the network through transactions (deploys). Bonding requests accumulate in a "bonding draw set" in the proof of stake contract. The amount of staking REVs declared in the bonding request is moved from the declared wallet to the proof of stake contract. If multiple bonding requests that request to bond the same validator are submitted, the requested staking amounts of the latter are added to the former. At anytime, bonding requests can be withdrawn and locked up stake will be immediately withdraw-able. Every 10,000th block, as many requests are stake-weight-randomly selected from the bonding draw set to fill up the bonds map, but they sit in a "bonding staging set" for 10,000 blocks before actually being added to the bonds map. For example, if there are currently 72 bonded validators in the bonds map, 28 bonding requests in the queue will be selected.
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.
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.