*Below is a brief summary of the main sections contained in the POSDAO white paper. Please leave comments in the Google form.
|v1.4||6.11.2019||* Explanation and parameters related to native coin staking (single token) in addition to the dual token environment.
+ _erc20Restricted parameter in InitializedAuRa contract [9.2.1]
+ Native inflation distribution added [18.104.22.168]
* DPOS_INFLATION_RATE parameter was removed due to an updated the inflation formula .
* [Appendix C] updated with example inflation rate.
* Functionality extended to allow contracts deployment on an existing AuRa network rather than invocation only on the genesis block. [9.2.1]
* Various Figures updated to reflect MAX_VALIDATORS = 19.
* Additional blockRewardContractTransitions spec option added. [9.3]
|v1.3||5.20.2019||* Reference implementation network parameters updated based on stress testing results in production mode. MAX_CANDIDATES increased from 1500 to 3000 and MAX_DELEGATORS_PER_POOL increased from 200 to 3000 [9.4]|
|v1.2||4.29.2019||* note on paper layout to address different audiences [Intro]
* added MAX_DELEGATORS_PER_POOL parameter in response to stress testing; it is necessary to limit the amount of delegators to maintain a 5 second block time in AuRa
* clarified snapshotting process which occurs at the end of each staking epoch [4.2, 22.214.171.124]
* provided additional information around checkpointing to mitigate a long range attack [7.1]
|v1.1||4.09.2019||* automatic withdrawal of token orders replaced by manual token claims [4.5, 9.2.8]
* long range attack solution revised to include reasoning and link to weak subjectivity [7.1]
* reward distribution code rewritten and optimized [9.2.7]
* threshold for the reportMalicious function increased from ½ to ⅔. [9.2.6]
* xDai DPOS network parameter constants adjusted to:1500 MAX_CANDIDATES & 19 MAX_VALIDATORS [9.4]
|v1.0||3.29.2019||* Initial specification|
The POSDAO whitepaper is now published and available through the SSRN scientific research paper repository.
Proof of Stake Decentralized Autonomous Organization
AbstractIn this paper we introduce POSDAO, a Proof of Stake (POS) algorithm implemented as a decentralized autonomous organization (DAO). It is designed to provide a decentralized, fair, and energy efficient consensus for public chains. The algorithm works as a set of smart contracts written in Solidity. POSDAO is implemented with a general purpose BFT consensus protocol such as Authority Round (AuRa) with a proposer node and probabilistic finality, or Honey Badger BFT (HBBFT), leaderless and with instant finality. Validators are incentivized to behave in the best interests of a network through a configurable reward structure. The algorithm provides a Sybil control mechanism for managing a set of validators, distributing rewards, and reporting and penalizing malicious validators. The authors provide a reference POSDAO implementation, xDai DPOS, which uses xDai as a stable transactional coin and a representative ERC20 token (DPOS) as a staking token. The reference implementation functions on an Ethereum 1.0 sidechain and utilizes the AuRa consensus protocol. Assets are bridged between the Ethereum mainnet and the xDai DPOS network using several instances of the POA TokenBridge.
The POSDAO protocol provides an immediately available scalability solution for Ethereum 1.0, creating the opportunity for delegated staking, high transaction speeds, and low transaction costs. On a POSDAO enabled sidechain, candidates stake tokens (greater than a specified minimum candidate stake) to declare their intention to become validators on the network. Delegators can also stake tokens on these candidates, providing a “vote” for a particular candidate by contributing to their pool.
Validator sets are selected based on the size of their pool and a randomness beacon. The larger the pool size, the greater the probability of selection.
Once selected, validators are responsible for signing blocks and securing the network for a predetermined amount of time, called a staking epoch. During each staking epoch, the validators and the delegators who staked with them are rewarded with additional tokens for successful block production. At the end of each epoch, a new validator set is elected. This may consist of the same or different validators, depending on pool sizes, detection of any malicious behavior, and the number of viable candidates in the network.
The reward structure in POSDAO is highly configurable. Validators receive transaction fees, and validators and their delegators receive block rewards. Because POSDAO functions on an Ethereum sidechain, bridge rewards can also be introduced. Bridge exit and entrance fees (when assets are moved to and from the sidechain to the Ethereum mainnet) may be assessed and distributed to active validators and delegators.
POSDAO can also be implemented with a dual token structure, where one token is used for staking and a second token or coin is used for transactions. These tokens can have different properties (like a stable coin or a coin pegged to another asset), providing an opportunity to implement different reward models.
Rewards are distributed based on several (configurable) rules:
Each pool in the validator set receives an equal share of the block reward on block creation.
Pool rewards are distributed proportionally, as long as the total delegator’s stake is below 70%.
The validator is guaranteed to receive at least 30% of the pool reward. If the total delegator’s stake exceeds 70%, the delegators’ rewards are adjusted accordingly.
Example scenarios and in depth explanation of reward distribution are available in the paper.
Validator set formation
The maximum number of candidates and validators allowed in a network is set at network launch (default MAX_VALIDATORS = 19). Any Ethereum address can become a candidate when they place more than the minimum candidate stake onto their address. When a new staking epoch begins, the algorithm selects a new validator set from the current list of candidates using staking pool size and a random number generator to determine the next set.
When the set is determined, the algorithm takes a snapshot of their pools (which includes their stake as well as any delegators stake) at this time, and uses this snapshot to calculate reward distribution during the staking epoch. Additional staking or withdrawal to and from a pool during a staking epoch does not impact the current pool reward.
The POSDAO network may be initiated from the genesis block or the switch can be triggered on an existing chain. POSDAO can be configured to run as a stand-alone blockchain, or it can connect to other networks using a bridge or series of bridges. In the bridged network scenario, two instances of the POA TokenBridge are used to connect the POSDAO sidechain to the Ethereum Mainnet. Bridge entrance and exit fees are assessed to provide additional incentives for validators.
POSDAO algorithm design decisions are discussed, including the pluggable consensus layer, DPOS, and the underlying reward structures.
Consensus layer options: Chains may choose the underlying consensus algorithm that best suits their use cases and users.
DPOS: DPOS is known to provide a high level of scalability and can achieve better decentralization than proof-of-work mining at a much lower resource cost.
Minimum candidate stake: The minimum candidate stake discourages the potential centralization of candidate seats and deters a coordinated validator set attack.
Equal share of the block reward: This creates parity among the validators participating in each staking epoch.
Proportional reward distribution of 70/30%: The 70/30 distribution ratio is a common revenue sharing heuristic, providing a baseline incentive for validators and staking options for delegators.
Dual token environment: This setup allows for different incentivization constructs, including the use of stable transactional tokens and staking tokens with a configurable inflation rate (no inflation on the mainnet, annual inflation on the sidechain).
Misbehavior and consensus fault management
Blockchains are subject to many types of attacks. POSDAO is built to withstand known attacks and it is fortified against attacks specific to the implementation. A review of current attacks and POSDAO protocol solutions are presented.
The underlying consensus algorithm (AuRa or HBBFT) prevents several attacks, including Long Range, Nothing at Stake, and Fake Stake attacks.
To deter a Cloning attack, the AuRa protocol is modified in POSDAO to require 2/3 signature majority when signing blocks.
RANDAO attacks are addressed through the protocol design, where validators who do not reveal their secrets in an attempt to influence random number generation are subject to a participation ban.
Exit from Bridge attacks are prevented through safeguards enacted on the bridge itself, including elected bridge validators who are known and trusted organizations, and daily limits which cannot be exceeded.
Coordinated Validator Set attacks addressed by setting a high minimum stake for candidates during POSDAO setup.
Plans for future versions of POSDAO include:
HBBFT full implementation: The current implementation uses AuRa, HBBFT will be integrated with Parity.
Bridge governance development: Future releases will promote decentralization constructs for bridge validators.
Reward model analysis: Varying reward models and scenarios will be explored.
Hypothecation: It may be possible to allocate tokens “locked” in the bridge as loan collateral, providing another form of staking reward.
An in-depth description of the xDai DPOS implementation is provided, including details and functionality of all smart contracts and parameters for network setup, initialization, staking, and rewards.
Several modifications were made to the Parity client in order for it to function with a POSDAO network. These changes are also explained at a high level.
Included are an interactive reward distribution sheet, several reward distribution example scenarios, DPOS modeling results using NetLogo, and a summary of the changes that will be required to complete the Honey Badger BFT integration with Parity.
The latest pdf version of the complete white paper is available here v1.4 (1.9 MB)*
Please leave comments in the Google form.