POSDAO white paper

*Below is a brief summary of the main sections contained in the POSDAO white paper.

The latest pdf version (v1.9) of the complete white paper is available here

POSDAO - Proof of Stake Decentralized Autonomous Organization.pdf (2.3 MB)

Version Date Change Log
v1.9 6.16.2021 * Added Nethermind Client implementation
* Updated 70/30 reward distribution in reference implementation to straight proportional allocation
* Added potential implications for tx fee distribution related to EIP1559
v1.8 9.25.2020 * Add txPriority Contract
v1.7.1 5.19.2020 * Update wiki links to point to OpenEthereum wiki
v1.7 3.30.2020 * Updated terminology to include OpenEthereum (Rather than Parity) and STAKE token (rather than generic DPOS token).
* DPOS ERC20 tokens renamed to POSDAO ERC677 tokens (and ERC20-TO-ERC20 bridge mode changed to ERC677-TO-ERC677).
* Added qualifier to Equal Block Reward mechanism. If validators skip blocks their rewards are reduced accordingly. [​6.2.2​]
* Update image terminology.
* StakingAuRa.claimReward​function added (reward strategy updated from PUSH to PULL, where participants pull rewards) [​9.2.13​]
* Pending validator set functionality now uses boolean flag rather than a queue. (​ValidatorSetAuRa._pendingValidatorsCh anged​) [​9.2.4​]
* Debugging functionality added via RandomAura.setPunishForReveal​ function where punishments may be temporarily removed. [​9.2.5​]
* Added ERC20-to-Native bridge reward from Dai Savings Rate [​9.2.7.2]​
* parity_clearEngineSigner​RPCmethod added [​9.3​]
* xDai POSDAO network parameters updated
v1.6 7.22.2019 * Additional ​blockGasLimitContract​ spec option added. [​9.3​]
* Value of the COLLECTION_ROUND_LENGTH parameter decreased from 200 to 114. [​9.4​]
v1.5 6.24.2019 * Additional posdaoTransition spec option added [9.3]
* *AuRa​ stepDuration​ spec parameter extended. [​9.3​]
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 [9.2.7.4]
* DPOS_INFLATION_RATE parameter was removed due to an updated the inflation formula [3].
* [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, 9.2.2.5]
* 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.

POSDAO

Proof of Stake Decentralized Autonomous Organization

Abstract

In 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 POSDAO, which uses xDai as a stable transactional coin and a representative ERC677 token (STAKE) 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 POSDAO network using several instances of the POA TokenBridge.

Introduction

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.

Reward Distribution

The reward structure in POSDAO is highly configurable. Validators receive transaction fees (fees subject for re-allocation based on EIP1559 implementation), 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 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*:

*:exclamation:Note that the 70/30 rule described below has been deprecated as of 06/15/2021 to distribute rewards proportionally to all stakers (validators and delegators) based on amount staked.

  1. Each pool in the validator set receives an equal share of the block reward on block creation.

  2. Pool rewards are distributed proportionally when the total delegator’s stake is below 70%.

  3. The validator receives 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.

Network initialization

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.

Rationale

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: Delegated Proof-of-Stake 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. However, this is configurable and subject to change.

  • 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.

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.

Future directions

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. Update: Governance Board is now operational.

  • 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.

Reference implementation

An in-depth description of the xDai POSDAO 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 OpenEthereum client in order for it to function with a POSDAO network. These changes are also explained at a high level.

Appendices

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 OpenEthereum.

12 Likes

Paper updated 4/29/2019 to reflect the latest version 1.2.

3 Likes

Paper updated 4.24.2020 to reflect the POSDAO implementation version/parameters on xDai.

2 Likes