garious
commented
5 years ago Thanks @ericlwilliams! Can you move this to a PR creating a new file, rfcs/rfc-009-staking.md? And then change this issue to something that only describes the problem(s) being addressed, such as "No economic incentive to converge on a fork".
ericlwilliams
Initial proof-of-stake (i.e. using in-protocol asset, SOL, to provide secure consensus) design ideas outlined here. Solana will implement a proof of stake reward/security scheme for node validators on the network. Solana's Proof of History (PoH) network is an availability preferring, partially synchronous network with a chain-based Proof of Stake consensus design. In addition to environmental (i.e. energy) and security benefits, implementation of PoS consensus also:
While many of the details of the specific implementation are currently under consideration and are expected to come into focus through modeling work and parameter exploration on the Solana testnet, we outline here our current high level outline of the main components of the PoS system. Much of this thinking is based on the current status of Casper FFG, with optimizations and specific attributes to be modified as is allowed by Solana's PoH blockchain data structure.
General Overview
Solana's validation network design is based on a rotating, stake-weight randomly selected leader broadcasting network transactions in a Proof of History data structure to staked, validating nodes. These nodes, upon receiving the leader's broadcast, have the opportunity to vote on the current state and PoH height by signing a transaction into the PoH stream.
To become a Solana validator, a network node must deposit/lock-up some amount of SOL in a contract. This SOL will not be accessible for a specific time period. The precise duration of the staking lockup period have not been determined, however we can consider three phases of this time:
Solana's trustless sense of time and ordering provided by it's PoH data structure, along with it's avalanche data broadcast and transmission design, should provide sub-second finality times that scale with the log of the number of nodes in the network. This means we shouldn't have to restrict the number of validating nodes with a prohibitive 'minimum deposits' and expect to allow nodes to be able to become validators with nominal amounts of SOL staked. This should also render validation pools unnecessary and remove the concern for needing to put slashable stake at risk while relying on others to play by the rules.
Rewards
Rewards are expected to be payed out to active validators as a function of validator activity and as a proportion of the percentage of SOL they have at stake out of the entirety of the staking pool.
We expect to define a baseline annual validator payout/inflation rate based on the total SOL deposited. E.g. 10% annual interest on SOL deposited with X total SOL deposited as slashable on network. This is the same designed as currently proposed in Casper FFG which has additionally specified how inflation rates adjust as a function of total ETH deposited. Specifically, Casper validator returns are proportional to the inverse square root of the total deposits and initial annual rates are estimated as:
This has the nice property of potentially incentivizing participation around a target deposit size. Incentivisation of specific participation rates more directly (rather than deposit size) may something also worth exploring.
The specifics of the Solana validator reward scheme are to be worked out in parallel with a design for transaction fee assignment as well as our storage mining reward scheme.
Slashing rules
Unlike proof-of-work where off-chain capital expenses are already deployed at the time of block construction/voting, proof-of-stake systems require capital-at-risk to prevent an optimal strategy of multiple chain voting. We intend to implement 'slashing' rules which, if broken, result some amount of the offending validator's deposited stake to be removed from circulation. Given the ordering properties of the PoH data structure, we believe we can simplify our slashing rules to a simple voting lockout time attached to each vote.
I.e. Each vote has an associated lockout time (PoH duration) that represents a duration for which any additional vote from that validator must be in a PoH that contains the original vote, or a portion of that validator's stake is slashable. This duration time is a function of the initial vote PoH count and all additional vote PoH counts. We're currently exploring functional forms such as:
Lockouti(PoHi, PoHj) = PoHj + K * exp((PoHj - PoHi) / K)
Where PoHi is the height of the vote that the lockout is to be applied to and PoHj is the height of the current vote on the same branch. Lockouti then represents the PoH time for which the validator submitting vote i is at risk of slashing if they submit a vote on a PoH that doesn't contain vote i. I.e. if the validator submits a vote on a different PoH branch on any PoHk where k > j > i and PoHk < Lockout(PoHi, PoHj), then a portion of that validator's stake should be slashed.
The exponential nature of the lockout time limits the ability for adversarial nodes, that may have the ability to generate faster (against clock time) PoH streams, from creating partitions and censoring nodes. Due to the highly optimized hardware properties of the
sha256hash function, a faster PoH stream from a validator isn't likely to be significant and their PoH stream will increase in difference only linearly. Additionally, leader rotation times reduces the global speedup available to a malicious node to the fraction speed-up they've achieved multiplied by the % of stake they have in the total deposit (i.e. the % of time they are elected leader).It is likely that a reward will be offered as a % of the slashed amount to any node that submits evidence of this slashing condition being violated to the PoH.
Partial Slashing
In the schema described so far, when a validator votes on a given PoH stream, they are committing themselves to that branch for a time determined by the vote lockout. An open question is whether validators will be hesitant to begin voting on an available branch if the penalties are perceived too harsh for an honest mistake or flipped bit (corrupted software).
One way to address this concern would be a partial slashing design that results in a slashable amount as a function of either a) the fraction of validators, out of the total validator pool, that were also slashed during the same time period (ala Casper), b) the amount of time since the vote was cast (e.g. a linearly increasing % of total deposited as slashable amount over time), or both. This is an area currently under exploration.
Penalties
As previously discussed annual validator reward rates are to be specified as a function of total amount deposited. These rates are to be rewarded to validators who are online and actively participating in the validation process throughout the entirety of their validation period. For validators that go offline/fail to validate transactions during this period, their annual reward will be effectively reduced.
Similarly we may consider an algorithmic reduction in a validator's deposited amount in the case that they are offline. This design would be strucutred to help long-lived partitions eventually reach finality on their respective chains as the % of non-voting total stake is reduced over time until a super-majority can be achieved by the active validators in each partition. Different rates of deposit reduction may be considered depending on the size of the partition (e.g. reductions in smaller partitions slower than larger partitions)