...
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 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 100 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 10,000th 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.
Transactions are signed to a particular validator. Half of the transaction Transaction fees from processed transactions are credited to the creator of the block in a split stake-weighted to the "rewards map" in the proof of stake contract, and the other half is burned. The "rewards map" is similar in structure to the "draw map" consists of n key-value pairs where the key is the bonded validator and the value is their corresponding , but instead of holding stakes, the rewards map holds the accumulated share of transaction fees, denominated in REVs.
Every 10,000 blocks, all validators are taxed 100 REV from their 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 submitted calls 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 "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. 50,000 LONG_RANGE_ATTACK blocks after the insertion of an entry into the withdrawal map, validators may withdraw the are sent their 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)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 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 feesNo protections as of now.
"Validator rotation slowing consensus": By having validator rotation only happen every 10,000 EPOCH blocks, we lower the overhead of validator rotation.
"Risk of lost funds from validation from software 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 bugThe coop will have a policy to refund lost REVs that are from software bugs.
"Not enough at stake validating": Only one validator can unbond every 10,000 blocksNo 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": 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 As transaction fees are split stake-weighted, validators have no incentive to steal transactions from each other.
"Lazy validator": By having a carrying cost of stake, validators Validators who aren't able to produce blocks will want to leave the validating poolbe 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.
...
"Preventing long-term oligopoly": It is possible to have the same 100 validators forever control the chain - oh wellWe automatically rotate the set of active validators.
"Not having idle hardware": By having a bonding staging an unlimited draw set, it allows time for validators to purchase/ready hardware for hardware owners always have a chance of validating.