POSDAO白皮书

POSDAO

Proof of Stake Decentralized Autonomous Organization

Authors: Igor Barinov, Vadim Arasev, Andreas Fackler, Vladimir Komendantskiy, Andrew Gross, Alexander Kolotov, Daria Isakova

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 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代币Bridge.

Table of Contents

  1. Introduction 3

    1. Proof of Stake model 4
    2. Delegated Proof of Stake 5
    3. Decentralized Autonomous Organization (DAO) 5
    4. POSDAO consensus model 5
  2. Terminology 7

  3. Reward distribution 8

    1. Configurable reward structure 9
      1. Transaction fees 9
      2. Bridge fees 9
      3. Fixed block rewards 9
    2. Three rules of reward distribution 10
    3. Distribution examples 11
      1. Pools receive an equal reward per block 11
      2. Validator shares the reward with delegators proportionally within a pool. 11
        1. Case with no delegators 12
        2. Case with one delegator and one validator 12
        3. Case with multiple delegators 13
      3. Validator shares a reward with delegators with proportion 30% to 70% within apool. 14
        1. Case with one delegator 14
        2. Case with multiple delegators 15
  4. Validator set formation 15

    1. Network participants 15
    2. Staking epochs 16
    3. Becoming a candidate 16
    4. Candidate pools 16
    5. Staking and withdrawal to/from a pool 16
    6. Moving stakes 17
    7. Randomness when selecting a validator 18
  5. POSDAO network initialization 18

    1. Bridged network scenario 19
      1. Bridge 1: ERC20-to-ERC20 bridge 19
        1. ERC20-to-ERC20 bridge entrance and exit fees 20
      2. Bridge 2: ERC20-to-Native bridge 225.1.1.1 ERC20-to-Native bridge entrance and exit fees 22
      3. Bridge setup and initial validators 24
    2. Initialization parameters 26
      1. Recommendations 27
  6. Rationale 27

    1. Consensus Mechanisms 27
      1. Consensus layer options 27
      2. Delegated Proof of Stake (DPOS) 28
    2. Reward Structure 28
      1. Minimum candidate stake 28
      2. Equal share of the block reward 28
      3. Proportional reward distribution of 70/30% 28
      4. Dual代币 Environment 29
  7. Misbehavior and consensus fault management 29

    1. Long Range attack 30Problem 30Solution 30
    2. Nothing at Stake attack 30Problem 30Solution 30
    3. Fake Stake attack 31Problem 31Solution 31
    4. Cloning attack 31Problem 31Solution 32
    5. POSDAO implementation specific attacks 32
      1. RANDAO attack 32Problem 32Solution 32
      2. Exit from Bridge attack 33Problem 33Solution 34
      3. Coordinated Validator Set attack 34Problem 34Solution 34
  8. Future directions 34

    1. Honey Badger BFT full implementation 34
    2. Bridge governance development 35
    3. Reward model analysis 35
    4. Hypothecation 35
  9. Reference implementation notes 35

    1. POSDAO smart contracts 35
    2. Implementation details 37
      1. Network startup 37
      2. Placing stakes 38
        1. DPOS ERC20 staking tokens 39
        2. Initial validator stakes 39
        3. Candidate stakes 39
        4. Delegator stakes 39
        5. Staking window 40
        6. Helpful StakingAuRa getters 40
      3. New staking epoch, validator selection, and finalizing changes 40
      4. Validator set changes and validator set queue 42
      5. Random seed accumulation 42
      6. Removing malicious validators 44
      7. Block reward distribution 45
        1. ERC20-to-Native bridge fee distribution 46
        2. ERC20-to-ERC20 or Native-to-ERC20 bridge fee distribution 46
        3. Inflation distribution 46
      8. Withdrawing stakes 46
      9. Moving stakes 48
      10. Voluntary exit from a validator set 48
      11. Unremovable validator 48
      12. Zero gas price and service transactions 49
    3. Modified Parity client for AuRa 49
    4. xDai DPOS network parameters 50

Appendix A: DPOS Reward Distribution 51

Appendix B: DAI-to-xDai / ERC20-to-Native bridge example scenario 52

Appendix C: DPOS / ERC20-to-ERC20 bridge example scenario 54

Appendix D: DPOS modeling 57

Additional network statistics 58

Appendix E: Honey Badger BFT (HBBFT) integration 59

References 60

  1. Introduction

    While Ethereum 2.0 (Serenity) will bring Proof of Stake Sybil control and many other innovations to the Ethereum ecosystem, the completion date is currently unknown. Following completion, Ethereum 1.0 will continue to provide a viable and usable network, requiring long term support and optimization. The POSDAO (Proof of Stake Decentralized Autonomous Organization) protocol provides an immediately available scalability solution for Ethereum 1.0, creating the opportunity for staking and delegated staking, very fast transactions, and very low transactional costs. POSDAO runs on a fully compatible EVM-based sidechain, allowing for mainnet interoperability while providing greater efficiency, lower fees, configurability, and other benefits relative to current EVM consensus implementations.

    In addition to slow and costly transactions, there is increasing evidence that Nakamoto consensus (also known as Proof of Work) models are not ecologically viable in the long term. Bitcoin currently uses “at least 2.55 gigawatts of electricity”, with the potential to consume “7.67 gigawatts in the future”, comparable to the total usage of countries like “Austria (8.2 gigawatts)[1].” As a result, more blockchain networks are adopting Proof of Stake (POS) and Delegated Proof of Stake (DPOS) protocol variants as consensus alternatives[2]. These protocols are responsible for designating the network nodes that process transactions and update the ledger in a distributed system. They have been shown to provide the requisite security and consensus for a blockchain, and offer improved efficiency over current Nakamoto implementations[3]. In POSDAO, the POS algorithm is implemented as a decentralized autonomous organization (DAO).

    Participants in POS protocols stake assets, in the form of tokens or coins, to protect the network and achieve agreement regarding blockchain transactions. There are many projects within the Ethereum ecosystem where project specific tokens are held by project supporters, however, these assets have limited utility. By converting project specific tokens to DPOS staking tokens, token holders can participate as validators or delegators in the consensus process on an Ethereum-based sidechain. They earn rewards (either block rewards or transactional rewards) based on their participation. This provides an opportunity for token holders to convert any amount of current holdings into staking tokens, which in turn earn reward-based dividends.

    While many POS and DPOS implementations are currently available, they often have set criteria which determine their base functionality and limit their potential usage. The parameters in the POSDAO chain are highly configurable. This includes the underlying consensus protocol, block reward functionality, transaction rate, staking specifications, and other implementation details.

    The reference implementation provides settings and parameters which can be changed depending on the purpose of the chain and the needs of its users.

    1. Proof of Stake model

      Consensus algorithms provide an economic incentive for honest protocol execution and decentralization. In a Proof of Stake (POS) model[4], individuals stake an amount of tokens in an effort to be selected as a block producer (validator). Validators are chosen based on numerous criteria; typically the amount of stake and a randomness beacon are used in the selection process. In exchange for successful block creation, validators are rewarded with additional tokens.

      A main advantage of a POS Sybil resistant system is the reduced energy expenditure in comparison to a Proof of Work (POW) model. Additionally, POS incentivizes validators to run high-bandwidth nodes and backup nodes for redundancy, which improves network throughput. POW, on the other hand, incentivizes the purchase of more mining hardware, which does not improve the maximum throughput.

      There are two major POS models: Chain-based proof of stake, which “[..] features a chain of blocks and simulates mining by pseudorandomly assigning the right to create new blocks to stakeholders, and Byzantine Fault Tolerant (BFT) proof of stake, where an existing BFT consensus is repurposed for Sybil control and economic incentive models”[5]. POSDAO utilizes smart contracts for the validator selection process. These validator sets then run the underlying consensus protocol. It can be configured to use Parity’s AuRa consensus engine[6] or Honey Badger BFT[7].

    2. Delegated Proof of Stake

      Delegated Proof of Stake (DPOS)[8] extends the POS model to allow additional individuals to stake their tokens on potential validators (candidates), without participating in block production themselves. Candidates who collect a higher percentage of tokens have greater odds of becoming validators on the network. Rewards are then divided amongst the validators and the staking entities (delegators).

      DPOS provides the opportunity for delegators to “vote” on potential validators by staking tokens on them. Candidates are incentivized to maintain a good reputation in order to attract more delegators and increase their chances of becoming validators. POSDAO is designed to support a DPOS model.

    3. Decentralized Autonomous Organization (DAO)

      A DAO is a self-sustaining, virtual entity defined by “smart contracts that contain the assets and encode the bylaws of an entire organization.[9]” All financial transactions, rules, and decisions are enacted and stored on the blockchain, creating a transparent and verifiable record. Rules are initially set forth in smart contracts, and members (participating token holders) interact according to these regulations to further the goals of the organization. Organizational rules can be modified through mechanisms contained in the on-chain contracts or through an off-chain governance process, such as subjective resolution and/or software updates.

    4. POSDAO consensus model

      POSDAO consensus implements a layered POS model connected by smart contracts on a public blockchain (see Figure 1 below). Sybil control and incentives exist in smart contracts working within the EVM and the execution state is stored on a public chain implementing the POSDAO consensus. The underlying BFT consensus exists on the network protocol level. This model requires modifications to the BFT consensus algorithm implementations in the Ethereum client to facilitate information exchange between smart contracts and the consensus layer. This includes communication relays regarding consensus faults and validator set management.

      Note that the AuRa implementation of POSDAO will be completed first, and HBBFT will be implemented in a future release.

      image

      Figure 1: Interactions between participants and primary consensus contracts in POSDAO.

  2. Terminology

    Term

    Math notation

    Definition

    Staking unit

    1μ ∈ M

    = {ETH, DAI, POA…}

    A token denomination used by actors of the algorithm for staking. Actors include candidates, validators, and delegators.

    Minimum candidate stake

    staμ

    min

    − number of staking units

    The minimum amount of staking units required to participate as a candidate for a validator slot.

    Candidate stake

    staμ st≥ stC

    min

    − number of staking units

    The amount of staking units a given candidate has staked on itself. If the candidate is selected as a validator, the candidate stake is referred to as validator stake without changing the notation.

    Minimum delegator stake

    staμ

    min

    − number of staking units

    The minimum amount of staking units required to participate in a pool as a delegator.

    Delegator stake

    staμ

    i

    D D

    st≥ stmin

    − number of staking units

    The amount of staking units the -th delegator contributed to a given pool.

    Candidate

    An Ethereum address which deposited at least the minimum candidate stake to form a new pool.

    Delegator

    An Ethereum address that allocates staking units to a candidate’s/validator’s pool. Delegators and the candidate/validator together form liquidity of the pool.

    Pool

    P st

    n

    = ∑ st stC

    st i

    i=1

    The total sum of staking units allocated to a candidate/validator. This includes all delegators’ staking units as well as units staked by the candidate/validator. The proportion of stake is used to determine pool reward distribution.

    Validator

    A candidate selected by the algorithm to participate in a validator set for a staking epoch.

    Validator set

    The set of validators selected for a staking epoch to keep consensus of a network. Each validator represents the validator’s pool.

    Initial validators

    The set of validators defined during network initialization.

    Staking epoch

    t

    The time duration (in blocks for AuRa, time in HBBFT) for which the validator set is selected. For example this is set to 120960 for a one-week timeframe with a 5 second block time (for AuRa).

    Pool reward

    P rw

    rw BR * 1

    j

    n

    = ∑ rrV

    i

    i=1

    − number of validators

    – number of delegators r− validator’s reward rD− delegator’s reward

    The block reward in reward tokens for a validator and delegators within a pool. The distribution between them is defined in 3. Rewarddistribution.

    Block reward

    BR

    The total number of reward tokens appropriated per block (or per amount of time for consensus algorithms like Honey Badger BFT). The BR is evenly distributed amongst all participating validator pools.

    Reward token

    T

    An ERC20 or Native token used to reward validators and delegators.

    image

  3. Reward distribution

    Reward distribution is the primary incentivization mechanism of the algorithm. In this section, we explain the reward distribution rules between validators and delegators within pools based on their contribution amounts.

    POSDAO provides the option to implement a dual token environment. This is not a requirement of the algorithm, but allows the opportunity to explore various economic incentives. In the reference implementation, the DPOS ERC20 token – bridged as an ERC677 representation – is used for staking. It is also used to provide token rewards from the ERC20-to-ERC20 bridge

    (entrance/exit fees), and block rewards. A second token (a native stable coin) is used for transaction fees (paid to validators only) and rewards from the ERC20-to-ERC20 bridge (entrance/exit fees).

    Block rewards are configurable and can be setup according to the requirements of the implementation. In the reference implementation, the block reward is paid via a 1% annual inflationary measure applied to the sidechain DPOS staking token only (see 9.2.2 for more reference implementation details).

    Additional rewards are determined through transaction fees (for validators only) and entrance/exit fees (for validators and their delegators) on the bridges (see 5.1).

    1. Configurable reward structure

      The following reward types may be implemented with the POSDAO algorithm.

      1. Transaction fees

        Each on-chain transaction is assessed a transaction (gas) fee. This fee is configurable, and the default is very low. The validator that seals the block (in the AuRa implementation) collects any transaction fees associated with that block. In HBBFT, fees will be split equally among the validators. This reward is not distributed to the delegators in the pool, it is only awarded to validators.

      2. Bridge fees

        If a bridge is used in the implementation, bridge fees may be assessed when assets are transferred between chains (see 5.1 for details). An entrance fee is charged when assets are moved from the Ethereum mainnet to the sidechain, and an exit fee assessed when the asset is moved back to the mainnet. The fees are distributed to validators and delegators based on their staking ratios (see 3.2).

      3. Fixed block rewards

        When a new block is produced the protocol passes the list of active validators into a reward distribution function. The reward function mints reward tokens (or native coins depending on the network settings and bridge mode) for all active validators and their delegators. If a validator did not participate in the consensus process (due to misbehavior), its pool is not included in the reward distribution.

        To calculate block rewards, the total stake amount (calculated from the beginning of the staking epoch) is multiplied by a constant (inflation rate) and distributed among validators and their delegators. See 9.2.7 for more details based on our reference implementation.

        image

        Figure 2: In this example, transaction fees are awarded to the validator only, and bridge fees and block rewards are distributed between the node validator and the associated delegators.

    2. Three rules of reward distribution

      In order to maintain fairness and incentivize elected validators, reward distribution is calculated according to the following rules:

      1. Each pool within the validator set receives an equal share of the block reward on block creation.
      2. Pool rewards are proportionally distributed between a validator and the staking delegators, as long as the total delegators’ percentage of stake is below 70%.
      3. The validator is guaranteed to receive at least 30% of the pool reward. If the total delegators’ stake exceeds 70%, the delegators’ rewards are adjusted accordingly and the validator receives 30%. Note: This parameter is configurable, and we will conduct statistical analysis to determine its efficacy in our reference implementation.

      See Appendix A for a detailed example.

    3. Distribution examples

      1. Pools receive an equal reward per block

        Let’s introduce a pool reward per block. We assume it is defined on network startup.

        image

        Block reward 1 reward token

        If there is one validator in a validator set per a given staking epoch, that validator’s pool will receive 100% of the block reward.

        ID

        Pool reward

        Validator A

        100% of block reward

        Let’s assume the minimum candidate stake is one staking token and the minimum delegation stake is 0.01 staking tokens.

        Minimum candidate stake

        1 staking token

        Minimum delegation stake

        0.01 staking tokens

        If there are two validators in a validator set per a given staking epoch, even if their pools have a

        different amount of staking tokens (st A =/ st B )

        reward.

        , the pools will each receive 50% of the block

        ID

        Number of staking tokens

        Pool reward

        Validator A

        1

        50% of block reward

        Validator B

        2

        50% of block reward

      2. Validator shares the reward with delegators proportionally within a pool.

        When a share of the total amount staked by delegators is less than or equal to 70% of a pool, the reward is distributed proportionally among participants.

        n

        D

        ∑ sti

        i=1

        Pst

        ≤ 0.7

        st

        D

        image

        r

        P

        i

        rw i

        st

        V

        st C

        P

        rw *

        st

        1. Case with no delegators

          A validator owns 100% of the pool reward.

          Staking tokens

          Pool reward, %

          image

          Fig.1: Reward distribution for a single validator without delegators

          1

          100

          Blue validator

          1

          100

        2. Case with one delegator and one validator

          The delegator stakes an amount less than 70% of the total amount staked within a pool. The delegator shares the pool reward proportionally with the validator.

          Staking tokens

          Pool reward, %

          image

          Fig.2: Reward distribution for a single validator with a single delegator when the stake of the delegator is less than 70% of a pool

          1.25

          100

          Blue validator

          1

          80

          Red delegator

          0.25

          20

        3. Case with multiple delegators

          In this case, the sum of all delegators’ stakes is less than 70% of the total amount staked within a pool. The group shares the reward proportionally with the validator.

          Staking tokens

          Pool reward, %

          image

          Fig.3: Pool reward distribution for a single validator with multiple delegators when the sum of all delegators’ stake

          is less than 70% of a pool.

          1.25

          100

          Blue validator

          1

          80

          Red delegator 1

          0.05

          4

          Green delegator 2

          0.1

          8

          Yellow delegator 3

          0.1

          8

      3. Validator shares a reward with delegators with proportion 30% to 70% within a pool.

        When the total amount staked by delegators exceeds 70% of a pool, the delegators’ reward share is capped at 70%.

        n

        D

        ∑ sti

        i=1

        Pst

        > 0.7

        The validator’s reward never drops below 30% within a pool. This ensures nodes are incentivized to be validators themselves, rather than merely delegate.

        D

        r

        i

        = 70% rw *

        sti

        image

        n

        D

        r= 30%

        P rw

        ∑ sti

        i=1

        1. Case with one delegator

          One delegator staked more than 70% of a pool. The pool reward of the validator remains at 30%. The delegator receives 70% of the pool reward.

          Staking tokens

          Pool reward, %

          image

          Fig.4: Reward distribution for a single validator with a single delegator when the

          stake of the delegator is more than 70% of a pool

          4

          100

          Blue validator

          1

          30

          Red delegator

          3

          70

        2. Case with multiple delegators

          Multiple delegators staked amounts totaling more than 70% of a pool. The validator’s pool reward will not drop below 30%. The delegators proportionally share the 70% pool reward.

          Staking tokens

          Pool reward, %

          image

          Fig.5: Pool reward distribution for a single validator with multiple delegators when the sum of stakes of all delegators is more than 70% of a pool

          6

          100

          Blue validator

          1

          30

          Red delegator 1

          2

          28

          Yellow delegator 2

          3

          42

  4. Validator set formation

    Any address with the minimum required candidate stake can become a validator. When an address calls the addPool contract function and meets the minimum required candidate stake, it becomes a candidate and forms a new pool.

    1. Network participants

      The number of network participants is configurable and cannot exceed the values assigned to the MAX_CANDIDATES and MAX_VALIDATORS parameters.

      There is no limit to the number of participating delegators. Any arbitrary address with at least DELEGATOR_MIN_STAKE tokens (ERC20 or equivalent) can stake their tokens and become a delegator.

    2. Staking epochs

      The network’s operation is divided into staking epochs (STAKING_EPOCH_PERIOD – this value is configurable, the default is a one week cycle). A new staking epoch begins immediately following the termination of the previous epoch.

      At the beginning of each staking epoch, the algorithm selects a new validator set from the current list of candidates and creates a snapshot of the current state of the validators’ pools. If there are fewer than MAX_VALIDATORS candidates, every candidate becomes a validator. The snapshot is used to calculate the reward distribution for validators and delegators during each staking epoch.

    3. Becoming a candidate

      An arbitrary address A in the network launches its node and puts at least the minimum stake in ERC20 compatible staking tokens (CANDIDATE_MIN_STAKE) on its own address. Address A then specifies address B as the mining address using the addPool function. A new active pool is created for address A, and this account becomes a candidate account.

      • Address A is the staking address used to collect rewards and place stakes into their own pool.
      • Address B is used by the validator’s node to sign blocks, participate in the randomness beacon (see 4.7), and report on malicious validators.
    4. Candidate pools

      At the beginning of each staking epoch, the algorithm selects active candidate pools to participate as validators in the next validator set. Inactive pools are ignored.

      If a candidate withdraws all of their tokens from their pool, the pool becomes inactive and does not take part in the next validator selection process. The candidate can either fully withdraw their tokens and remove themselves as a pool, or partially remove their tokens (provided that they leave CANDIDATE_MIN_STAKE) and participate in later staking epochs.

    5. Staking and withdrawal to/from a pool

      Participants can stake or withdraw their tokens to or from pools during the majority of a staking epoch. The exception is a defined period at the end of each epoch

      (STAKE_WITHDRAW_DISALLOW_PERIOD). This measure prevents stake manipulation based on the random seed value generated at the very end of the epoch (see 4.7).

      • The total stake amount of a candidate or validator on their own pool cannot be less than CANDIDATE_MIN_STAKE.
      • The total stake amount of a delegator on any pool cannot be less than DELEGATOR_MIN_STAKE.

      The minimum candidate stake is relatively large, encouraging institutional investors to become candidates and validators. This large stake creates additional incentives for candidates to protect their nodes and prevent DoS attacks. However, DoS attacks on individual validator nodes are still possible. Part of the validator’s job is to defend against such attacks by using ISPs that provide DoS protection.

      Additional token staking or withdrawal to/from a pool during the current staking epoch (and thereby changing the size of the pool) does not impact the current pool reward. The reward is determined based on the pool’s state at the moment the staking epoch begins (see 4.2).

      However, these changes will impact validator selection probability for the following staking epoch.

      A participant cannot withdraw their tokens from an active validator’s pool unless the amount was staked during the current staking epoch (this amount hasn’t been allotted as a stake yet, so it can be withdrawn).代币 can be withdrawn from a candidate’s pool at any time (because the candidate is not a validator).

      If a participant (delegator or validator) wants to leave an active validator’s pool or reduce their staked amount, they can schedule a withdrawal from the pool. The selected amount is withdrawn automatically to the participant’s address (or to the validator’s staking address if the participant is a validator) at the beginning of the next staking epoch.

      If a validator wants to terminate their validator status on the next staking epoch, they can schedule a withdrawal of their staked amount or call the contract’s removePool function (in this case the pool becomes inactive and won’t be selected by the algorithm at the beginning of the next staking epoch).

    6. Moving stakes

      A participant (delegator or candidate) can move their full or partial stake amount from one pool to another without withdrawing the amount from the contract. Such a move is subject to the same withdrawal rules described above.

    7. Randomness when selecting a validator

      The protocol implements a random number generator similar to RANDAO, which is used to randomly select a set of validators from the group of candidates at the start of each staking epoch. Candidates with a larger pool have a higher probability of selection to a validator set for each staking epoch (candidates with higher stakes are probabilistically selected as validators for more staking epochs).

      image

      Figure 3: Validator set selection is determined by the validator/candidate pool size and a random value.

  5. POSDAO network initialization

    POSDAO smart contracts are initialized in the genesis block. Their pre-configured parameters are included in the bytecode, and the set of initial validators is also defined in these parameters.

    The network is initiated from the genesis block. In the reference implementation, all of the addresses in the network (including initial validators) have zero balances. There are no pre-initialized stakes for initial validators, so their pools are also empty.

    POSDAO may be configured to run as a stand alone blockchain. It can also run using a bridge or bridges which connect to one or more other networks. This bridged scenario is used in the reference implementation and is described below.

    1. Bridged network scenario

      The POA代币Bridge is used to connect Ethereum chain instances, allowing users to transfer assets between chains. In the reference implementation, two POA代币Bridge instances connect the POSDAO sidechain network to the Ethereum mainnet.

      Both bridges have their own validator sets which are not bound with the consensus validator set in the POSDAO network. Bridge validators are responsible for secure token transfer between chains, and they do not receive any reward for this service.

      image

      Figure 4: Reference implementation bridges between the Ethereum mainnet and the xDai DPOS network.

      1. Bridge 1: ERC20-to-ERC20 bridge

        The first bridge instance operates in the ERC20-to-ERC20 mode, connecting the POSDAO network with the Ethereum mainnet. This allows participants to bridge their staking tokens (DPOS ERC20 tokens in the reference implementation) from the mainnet to the POSDAO

        network (and move them back from POSDAO to mainnet when needed). See Appendix C for an example scenario.

        image

        Figure 5:代币 transfer between chains using the ERC20-to-ERC20 bridge. Note the ERC677 is an ERC20 extension which allows for easy transfer operations.

        1. ERC20-to-ERC20 bridge entrance and exit fees

          Entrance and exit fees are assessed when tokens are moved between the two networks. These funds are distributed to validators’ pools to provide staking incentives. The values are configurable (see the BRIDGE_ENTRANCE_FEE and BRIDGE_EXIT_FEE constants in 9.4), in this example it is set to 1% of the total bridge transaction token value.

          image

          image

          Figure 6-7: Bridge entrance and exit fees are distributed to active validator pools.

      2. Bridge 2: ERC20-to-Native bridge

        The second bridge instance operates using an ERC20-to-Native mode. In this scenario, participants bridge their ERC20 tokens from the Ethereum mainnet to the POSDAO enabled sidechain (and move the coins back to mainnet as needed). In the reference implementation we use DAI as the ERC20 token and xDai as the Native token.

        image

        Figure 8:代币 transfer between chains using the ERC20-to-Native bridge.

        5.1.1.1 ERC20-to-Native bridge entrance and exit fees

        Entrance and exit fees are also assessed when tokens are locked/unlocked and minted/burned between the two networks. These funds are also distributed to validators’ pools to provide staking incentives. The value is configurable, in this example it is set to 1% of the token-coin transfer amount. See Appendix B for an example scenario.

        image

        image

        Figure 9-10: Bridge entrance and exit fees are distributed to active validator pools

        5.1.3 Bridge setup and initial validators

        After the POSDAO network is started, the ERC20-to-ERC20 bridge is connected and initialized during the first staking epoch. Once the bridge is connected, the initial set of consensus validators (defined in the ValidatorSet smart contract) can bridge their DPOS ERC20 tokens from the Ethereum mainnet to the POSDAO network and place stakes into their own pools.

        Because the validators do not have native coins (xDai in our example implementation) when the network starts, they can make service transactions to the POSDAO contracts using zero gas.

        The validators can make unlimited service transactions but only within the scope of the consensus contracts. The TxPermission smart contract protects against possible spam sent from a validator. Figure 11 shows an example network initialization.

        If an initial staking epoch ends and there are no candidates (none of the initial validators made a stake into their pool), the initial validator set is retained for the following staking epoch.

        However, if at least one candidate appears (the address which added a stake to its pool), any initial validators with empty pools are removed from the set, and the candidate becomes a validator on the new staking epoch. Thus, if an initial validator wants to keep their seat after the initial staking epoch, they must place a stake into their own pool.

        After the bridge is connected, individuals can bridge their DPOS tokens and become candidates in the POSDAO network. Figure 12 illustrates the various possible interactions from a candidate’s address.

        If the number of candidates is greater than MAX_VALIDATORS at the beginning of new staking epoch, the validators are chosen randomly (using the randomness beacon) from the set of candidates: the larger the candidate’s pool, the higher probability the candidate has of becoming a validator.

        image

        Figure 11: Initialization of three initial validators and one candidate (random is not used here because the number of initial validators + candidates ≤ 22):

        image

        Figure 12: Candidate interactions from a single Ethereum address.

        5.2 Initialization parameters

        When a new network starts the initial validator set is populated. The number of initial validators is equal to the number of initial candidates.

        Example initial parameters at network start:

        Number of candidates

        30

        Number of validators

        4

        Number of delegators

        0

        Initial validator 1 (mining address)

        0x…

        Initial validator 1 (staking address)

        0x…

        Initial validator 2 (mining address)

        0x…

        Initial validator 2 (staking address)

        0x…

        Initial validator 3 (mining address)

        0x…

        Initial validator 3 (staking address)

        0x…

        Initial owner

        0x…

        In addition to the initial validators, an owner deploys the bridge contracts and has the ability to upgrade the bridge and consensus contracts when required (for example if bugs are found or the code needs to be modified). The owner should be a MultiSig smart contract which requires a trusted setup. The details of this setup can vary depending on the nature of the network. Future implementations may include a voting mechanism to allow validators the ability to vote on upgrades. This would alleviate the need for the owner contract.

        5.2.1 Recommendations

        When configuring the number of validators, the underlying consensus algorithm should be taken into account. For example, both our AuRa variant and HBBFT can tolerate up to and excluding one third of the validators being faulty. This means that 19 validators are more secure than 20, because in both cases, up to 6 faulty ones can be tolerated, but 7 out of 20 being faulty is more likely than 7 out of 19. In general, for these consensus algorithms, the number should be of the form 3 f + 1, e.g. 10, 13, 16 or 19.

        We also recommend setting the number of candidates much higher than the number of validators. This way, the number of possible validator sets is extremely high, and an attacker won’t be able to simply wait for a specific set to occur, where their nodes have a majority.

  6. Rationale

    1. Consensus Mechanisms

      1. Consensus layer options

        POSDAO is compatible with a number of consensus algorithms. Chains may choose the underlying algorithm that best suits their use cases and users. For example, AuRa provides a consistent block rate whereas Honey Badger BFT produces varying block rates based on network performance. One of these variants may be advantageous based on the purpose of the network. Note that the AuRa implementation will be completed first, and HBBFT will be implemented in a future release.

      2. Delegated Proof of Stake (DPOS)

        DPOS is known to provide a high level of scalability at the cost of limiting the number of validators on the network. While this creates a measure of centralization, researchers have argued that “a Byzantine quorum system of size 20 could achieve better decentralization than proof-of-work mining at a much lower resource cost.[19]” Block production is distributed equally among the preset number of elected validators, rather than concentrated among a few mining pools. Transactions can be processed quickly and efficiently, creating a highly scalable solution.

          1. Reward Structure

            1. Minimum candidate stake

              The minimum candidate stake discourages the potential centralization of candidate seats, where individuals may attempt to register many candidate nodes and thus control a large percentage of validator sets. A high minimum candidate stake also deters a malicious set of validators from attempting a coordinated validator set attack. This value is configurable based on the network purpose and size (see 9.4 for reference implementation parameters).

            2. Equal share of the block reward

              Each validator pool within a validator set receives an equal share of the block reward. While a higher stake impacts the odds of a candidate pool becoming a validator pool, each validator pool receives the same reward. This creates parity among the validators participating in each staking epoch.

            3. Proportional reward distribution of 70/30%

              The 70/30 distribution ratio is a common revenue sharing heuristic. It is a configurable option that can be changed during POSDAO deployment. When set at the initial value, delegators receive block rewards within their validator pool(s) up to 70% of the total pool value, incentivizing delegators to quickly fund candidate pools they believe should be validators.

              Once the 70% mark is reached, additional stake returns a proportionally smaller amount. At this point, delegators may choose to fund additional candidate pools, increasing the number and diversity of potential candidates, or stake additional tokens into the current pool, increasing the probability of a candidate pool becoming a validator pool in the next staking epoch.

              When the ratio is set to 70/30, a validator never receives less than 30% of the pool reward. Validators are responsible for running a node and a reward baseline prevents a situation where delegators can claim an overwhelming percentage of the reward. Once a pool reaches the 70/30 threshold, a validator may choose to increase their stake to attract additional delegator

              funds or to increase their position on the leaderboard. Since reputation is a valuable commodity,

              successful validator sets (those with a high stake, high transactional throughput, and consistent node uptime) will continue to attract stake from delegators.

            4. Dual代币 Environment

        The POSDAO implementation provides an opportunity to experiment with different incentivization constructs. Organizations may choose to use a single token for staking, transactions, and rewards, or separate tokens for transactions and staking. In the reference implementation, we use a dual token environment.

        For transactional purposes, we use a stable native coin (xDai, which is pegged to DAI on the mainnet). A stable currency allows users to predict fees and conduct transactions where prices will not fluctuate by large margins.

        For staking purposes, we use a token whose price is determined by the market. While there is more volatility with this token, it is not a transaction-based asset. Like other tokens, the price is determined by supply and demand in the Ethereum ecosystem. To provide block rewards, the DPOS staking token is subject to a configurable annual inflation rate on the sidechain, but not on the mainnet. On the mainnet, the token supply is fixed. On the sidechain, the amount grows by the annual inflation rate (in the reference implementation this is DPOS_INFLATION_RATE of all staked tokens). This block reward provides additional incentives for validators and delegators to continue staking.

  7. Misbehavior and consensus fault management

    In this section we review existing attacks on consensus algorithms and provide our solutions to avoid or mitigate them.

    Although POSDAO is a robust algorithm designed to withstand attacks and misbehavior, there are circumstances where the protocol (as well as many other protocols) is susceptible to influence by an alliance of bad actors. The amount of exposure is affected by the underlying consensus algorithm.

    Network Stall: Colluding validators can temporarily or indefinitely delay network messaging, resulting in a stalled network. This may also happen accidentally if many validator nodes crash or disconnect in parallel. With the modified AuRa consensus, the network may stall if 33% or more validator nodes are impacted (because the modified AuRa requires at least 67% of validators signatures). With Honey Badger BFT, 33% or more faulty nodes may cause network stalls.

    Majority Collusion: The protocol cannot protect against a majority of colluding validators. In both Honey Badger BFT and AuRa, 67% or more of colluding validators can alter the entire

    protocol by forking the chain, sealing erroneous blocks, double-spending, or re-electing themselves as validators.

    1. Long Range attack

      Problem

      An adversary creates an alternate chain (branch) starting from the genesis block. The branch contains a different historical record of transactions and can be maintained locally. Using various techniques, block production can be accelerated on the local branch to create a longer chain than the main (honest) chain. At this point, the branch can be made public, overtaking the honest chain as the ledger of record.

      Longer branches may be created in several ways: forging time stamps, gaining access to former validator’s keys, or collusion among former validators to quickly populate the branch (costless simulation[4]), or stake bleeding[10], where a malicious validator slows the honest chain by failing to validate blocks while simultaneously increasing stake on the alternate branch. When this attack is successful, an adversary can post a transaction to the honest chain, wait for confirmation, then present the longer branch to invalidate the previously confirmed transaction.

      Solution

      This issue is best solved at the level of the underlying consensus algorithm. Both choices we recommend are immune to it:

      • AuRa considers blocks to be final as soon as half the validators have signed them. In our modified AuRa implementation no more than 2*MAX_VALIDATORS/3 blocks can be reverted at all. In our reference implementation that means all but the last 13 blocks will never be changed.
      • Honey Badger BFT has instant finality, i.e. no block can ever be reverted.
    2. Nothing at Stake attack

      Problem

      In the event of a fork in the chain, either due to simultaneous block production or malicious intervention, validators may choose to continue generating blocks on both chains, thus collecting block rewards on both chains without penalty. In fact, “the optimal strategy for any miner (validator) is to mine on every chain, so that the miner gets their reward no matter which fork wins[11].” This attack reduces efficiency by slowing down consensus time. Moreover, it

      results in blockchain forks which weaken the ability of the blockchain to resolve double spending attacks and other threats[12].

      Solution

      This, too, depends on the underlying consensus algorithm’s ability to prevent forks:

      • Parity’s AuRa implementation includes a mechanism to report validators that propose more than one block with the same number. In other words: mining on a fork does result in a penalty on the main chain, so there is something at stake in that scenario.
      • With Honey Badger BFT, it is impossible to create a fork in the first place, unless more than two-thirds of the validators collude. In addition, the authors’ implementation detects and reports misbehaving nodes.
    3. Fake Stake attack

      Problem

      In POSv3 (Bitcoin-based) networks, headers and blocks are sent as separate data structures and committed to storage before all validation checks are complete. These checks are sufficient in Proof of Work implementations, however in Proof of Stake implementations several vulnerabilities are created[13]. An attacker can flood a node with either fake block headers or fake blocks filled with arbitrary values. The RAM (headers) or disk space (blocks) is filled before validation checks are run, and the node is rendered unusable. A variation of this attack, called a “spent stake attack[14],” impacts pre-POSv3 networks that utilize Unspent Transaction Outputs (UTXOs) to record transactions. In this case, an attacker can amplify their apparent stake because validation checks do not differentiate between spent and unspent UTXOs. With this apparent stake, the attacker can mine POS blocks at a past time and then use these invalid blocks to overwhelm a node’s disk space.

      Solution

      In POSDAO, stake is not used directly to produce a block. Instead, the stake makes it more likely to be selected as a validator, and validators take part in an underlying consensus protocol that produces blocks independent of the stakes. Depending on that protocol, block headers can actually be validated very quickly: In AuRa the header is the step number and the signature by the block’s proposer, and in Honey Badger BFT it is a threshold signature.

    4. Cloning attack

      Problem

      The default Parity AuRa protocol is vulnerable to an attack[15] where a malicious validator may clone their node (create 2 or more instances of the same validator with the same public/private key pair), create a network partition (for example by delaying messages[16] ), and then use these cloned nodes on both sides of the partition. Because AuRa requires 1/2 of the validators to be

      honest, using the cloned nodes gives the illusion to the block validators on each partition that their group contains an honest majority.

      Once the blockchain is divided, the attacker issues conflicting transactions to each group, creating a double-spend scenario. The attacker waits for the transactions to be committed, then signs an additional block on one of the partitions (whichever one the attacker wants to preserve). This ensures the partition with this additional block becomes the longest chain (it has the greatest height) and it is accepted by the remaining nodes as the canonical chain. The other partition disappears, along with the transactions that were already accepted there.

      Solution

      Increasing the required number of signatures to 2/3 of validators rather than 1/2 of validators in the AuRa implementation is sufficient to protect against this type of attack. As long as the number of malicious validators is less than 1/3 of the total, the modified algorithm can guarantee safety, and liveness is still preserved (although block times may be impacted slightly in the

      event of a network partition). We have modified the AuRa protocol to utilize a 2/3 majority in order to protect against a cloning attack.

    5. POSDAO implementation specific attacks

      1. RANDAO attack

        Problem

        The POSDAO implementation requires a reliable source of randomness to manage validator sets. For AuRa we use the same algorithm as RANDAO[17], a widely used decentralized random number generator. In a “look-ahead” attack scenario, an attacker exploits the RANDAO reveal functionality by skipping block production. In order to be viable, this type of attack typically requires collusion or control of multiple nodes and a willingness to forfeit the block reward.

        When an attacker skips block validation, they can use the revealed information to pre-compute the possible outcomes of “(possibly many)” reveal strategies…and thus may anticipate the effects of their contribution to the process and bias the generated random number to their advantage.[18]

        Solution

        POSDAO contracts know whether a validator revealed their secret or not. If the validator didn’t reveal more than 20 times per staking epoch (this value is calculated based on the STAKE_WITHDRAW_DISALLOW_PERIOD and COLLECTION_ROUND_LENGTH constants),

        they are treated as malicious at the last block of that epoch and are removed by the algorithm from the list of active pools. In this case, the validator and all their delegators are marked as banned for the next 90 days (BAN_PERIOD), and they cannot withdraw their stakes from the

        banned pool during that period. The banned pool cannot participate in the following staking epochs for 90 days.

        This limit of 20 allowed skips per staking epoch is to avoid punishing validators for temporary outages. However, it also allows malicious validators to influence the outcome by faking such an outage. This tradeoff avoids sometimes banning honest validators with connection problems at the cost of making the random numbers less secure. When the numbers are used for high-value applications (e.g. a casino game with high stakes), the limit should likely be 0, and the validators should be expected to run multiple nodes or take other measures to prevent any outages.

        If a validator decides not to reveal their secret on the last reveal round of a staking epoch (to influence the outcome), they are treated as malicious. It is the validator’s responsibility to ensure their node is functional and connected during the final blocks of a staking epoch. They will be removed even if they have merely lost their connection during this phase.

        We recommend validators run two separate nodes simultaneously with different internet connections to ensure reliability: a primary node with the engine_signer option and a secondary node without that option but with a guard script which sets that option for the secondary node dynamically when the first node goes offline. Since running nodes in the cloud is not recommended (for security reasons), each validator should have nodes in multiple secured data centers.

        During the last 6 hours (STAKE_WITHDRAW_DISALLOW_PERIOD) of a staking epoch (this duration is configurable), no one can stake or withdraw, preventing any possible influence to the outcome.

        The only possible attack is if a validator chooses not to reveal the secret at the end of the staking epoch. This results in a freeze of the validator’s stakes (and all delegators that delegated stake to them) and a ban from participation for 90 days (BAN_PERIOD).

      2. Exit from Bridge attack

        Problem

        To achieve interoperability with Ethereum, multiple bridge instances can connect the POSDAO chain to the Ethereum mainnet (see 5.1 for details). Validators on the bridge are responsible for locking assets on one side of the bridge and minting assets on another. These operations require multiple signatures from a number of validators before they are performed. The bridge validators are distinct from validators on the POSDAO chain, and each bridge instance requires a predetermined set of validators (they may be the same or separate for each bridge).

        A colluding majority of bridge validators (either malicious or compromised nodes) could commandeer the bridge contracts and mint assets without the corresponding locked assets. This would create tokens or coins which are not backed by real assets. A colluding majority could also unlock assets on the other side of the bridge and drain the locked funds.

        Solution

        Separate from the POSDAO consensus validators, the bridge validators are known individuals who stake their reputations to secure the bridge contracts. These individuals (typically organizations) are community participants who agree to take on the responsibilities of managing the bridge. The bridge validation set does not rotate on a regular basis, although validators may be added or removed through a governance process. In addition, there are daily limits which safeguard against unchecked asset creation, destruction, or transfer. If a limit is exceeded, any transaction which requests to relay assets will fail.

      3. Coordinated Validator Set attack

        Problem

        A colluding set of malicious validators (greater than 67% of the set) could subvert the network by deploying new POSDAO contracts, changing the spec.json on their nodes, and then restarting their nodes. The new spec.json file would contain a new block number in engine.authorityRound.params.validators.multi (see https://github.com/poanetwork/poa-chain-spec/blob/core/spec.json). This would create a hard fork, and the validators would control the code of the contracts.

        Solution

        As mentioned in the introduction of section 6, the protocol itself cannot protect against a majority of colluding validators. However, increasing the CANDIDATE_MIN_STAKE parameter greatly reduces the feasibility of this attack, making it extremely expensive for a conspiring group to attempt. By increasing the value of this constant, the summary costs for a group are vastly increased, discouraging any efforts to coordinate a malicious takeover.

  8. Future directions

    1. Honey Badger BFT full implementation

      While the POSDAO algorithm is configurable to allow for different consensus mechanisms, AuRa consensus is currently the only method fully supported by the protocol. We are working to integrate HoneyBadger BFT as an alternative pluggable consensus. See Appendix E for additional details.

    2. Bridge governance development

      In a bridged scenario, bridge validators are granted multisig owner status. They are trusted during launch, and in the reference implementation are known, credible organizations. We will explore bridge governance strategies to promote further decentralization for future releases.

    3. Reward model analysis

      Highly configurable incentivization structures allow us to model different reward scenarios (see Appendix D). We will continue to test additional designs to fine-tune and explore the impact of different reward models.

    4. Hypothecation

      It is possible to allocate tokens “locked” in the bridge as collateral for loans through cryptocurrency lending services such as Compound. Guarantees must be in place so that any locked funds are returned on request, whenever a bridge transfer is initiated. We will explore this methodology to ensure it is sound, and analyze the costs/benefits of this novel approach for providing additional staking incentives.

  9. Reference implementation notes

    1. POSDAO smart contracts

      POSDAO is configured using a set of Solidity smart contracts to implement consensus, rewards, and staking logic.

      • BlockRewardAuRagenerates and distributes rewards according to the logic and formulas described in section 3. Main features include:
        • distributes the entrance/exit fees from the ERC20-to-ERC20, Native-to-ERC20, and/or ERC20-to-Native bridges among validators and their delegators;
        • distributes staking tokens minted by 1%/year inflation among validators and their delegators;
        • mints native coins needed for the ERC20-to-Native bridge;
        • makes a snapshot of the validators and their delegators at the beginning of each staking epoch and uses that snapshot during the staking epoch to accrue rewards to validators and their delegators.
      • Certifier: allows validators to use a zero gas price for their service transactions (see the Parity Wiki for more info). The following functions are considered service transactions:
        • ValidatorSet.emitInitiateChange

        • ValidatorSet.reportMalicious

        • RandomAura.commitHash

        • RandomAura.revealSecret

      • InitializerAuRaused once on network startup and then destroyed on genesis block. This contract is needed for initializing upgradable contracts on the genesis block. The bytecode of this contract is written by the scripts/make_spec.js script into spec.json along with other contracts.
      • KeyGenHistorystores the validator’s public keys needed for the Honey Badger BFT engine and for storing events used by HBBFT nodes.

      • RandomAuRagenerates and stores random numbers in a RANDAO manner (and controls when they are revealed by AuRa validators). Random numbers are used to form a new validator set at the beginning of each staking epoch by the ValidatorSet contract. Key functions include:
        • commitHash and revealSecret. These can only be called by the validator’s node when generating and revealing their secret number (see RANDAO to understand the principle). Each validator node must call these functions once per “collection round.” This creates a random seed which is used by the ValidatorSetAuRa contract;
        • onFinishCollectRound. This function is automatically called by the

          BlockRewardAuRa contract at the end of each “collection round.” It controls the reveal phase for validator nodes and punishes validators when they don’t reveal (see 7.5.1 for more details on the banning protocol).

      • Registrystores human-readable keys associated with addresses, like DNS information (see the Parity Wiki). This contract is primarily required to store the address of the TxPermission contract (see the Parity Wiki for details).
      • StakingAuRacontains staking logic including:

        • creating, storing, and removing pools by candidates and validators;
        • staking tokens by participants (delegators, candidates, or validators) into the pools;
        • storing participants’ stakes;
        • withdrawing tokens by participants from the pools;
        • moving tokens between pools by participants;
        • performing automatic token withdrawals at the end of a staking epoch if requested by participants.
          • TxPermissioncontrols the use of a zero gas price by validators in service transactions, protecting the network against “transaction spamming” by malicious validators. The protection logic is declared in the allowedTxTypes function.
          • ValidatorSetAuRastores the current validator set and contains the logic for choosing new validators at the beginning of each staking epoch. The logic uses a random seed generated and stored by the RandomAuRa contract. Also, ValidatorSetAuRa along with the modified Parity client is responsible for discovering and removing malicious validators. This contract is based on ReportingValidatorSet described in the Parity Wiki.

          Note that HBBFT contracts implementations are not fully finished, and they are not listed nor described here.

          For a detailed description of each function of the contracts, see the source code.

    2. Implementation details

      The following detailed outline is provided for the xDai DPOS AuRa implementation. Note that these details may change as further optimizations are introduced. Any protocol changes will be documented in updated versions.

      1. Network startup

        Before the network starts, we compile all consensus contracts and write their bytecodes in the spec.json file with the make_spec.js script. The compiled bytecode contains constructor parameters for those contracts which have a constructor.

        The network should have several initial validators which are defined in the constructor of the InitializerAuRa contract. We pass their addresses to the make_spec.js (example) along with the other necessary parameters to configure the network on the genesis block.

        After the spec.json file is ready, the initial validators must configure and start their Parity nodes. Each node uses the spec.json as a chain specification.

        The contracts’ bytecodes are written to the chain on the genesis block.

        Once the network is started, the ValidatorSetAuRa.finalizeChange function is called by the system at the beginning of block #1 (see the Parity Wiki for details). This function sets the initiateChangeAllowed boolean flag to true (this flag is used by the ValidatorSetAuRa.emitInitiateChange function which is called by a validator’s node

        when there is a non-empty pending validator list). The

        ValidatorSetAuRa.finalizeChange function is described in more detail below.

        Beginning from the genesis block, the initial validators do not have stakes because an ERC contract is not yet deployed. They are able to place stakes after the ERC contract is deployed and the ERC20-to-ERC20 and ERC20-to-Native bridges are installed.

        In addition to the initial validators, we also define the contracts’ owner. The owner is an address which is used for the bridge deployments and future contracts’ upgradability. Initially, the owner can make zero gas price service transactions because there are no native coins on its balance.

        When the ERC contract and the bridges (ERC20-to-ERC20 and ERC20-to-Native) are deployed by the owner, the following functions are called:

        • BlockRewardAuRa.setErcToErcBridgesAllowed

        • BlockRewardAuRa.setErcToNativeBridgesAllowed

        • StakingAuRa.setErc20TokenContract

        • ERC677BridgeTokenRewardable.setBlockRewardContract

        • ERC677BridgeTokenRewardable.setStakingContract

        Then the owner:

        1. Deploys the MultiSigWallet contract with the trusted addresses defined in its constructor.
        2. Calls the transferOwnership function (it may have another name depending on the contract) for each of the contracts it deployed and for each consensus contract.
        3. Passes its address to the Certifier.revoke and TxPermission.removeAllowedSender functions to disallow itself from using zero gas price service transactions. At this point, the owner becomes a regular address without special system rights.

        As each block is closed, the BlockRewardAuRa.reward function is called by the validator’s node which created that block. This is a Parity feature and it occurs for each block (with no gaps

        – see https://wiki.parity.io/Block-Reward-Contract.html). This function primarily exists for dynamic block rewards, but we use it for DPOS because BlockRewardAuRa.reward has no

        block gas limit, allowing us to make a lot of calculations. This function is described in more detail

        below.

      2. Placing stakes

        During the first staking epoch the initial validators place stakes into their own pools in order to retain their seats after the first staking epoch finishes.

        Each validator has two addresses: a mining address and a staking address. The mining address

        is used by the validator’s node (this address must be specified as engine_signer and unlock in

        theParity node configuration toml file) to make zero gas price service transactions. The staking address is used for other purposes (placing stakes, storing tokens, etc.)

        To retrieve the mining address by its staking address, and vice versa, the ValidatorSetAuRa.miningByStakingAddress and stakingByMiningAddress getters can be used.

        Staking tokens are acquired from the Ethereum mainnet (the foreign network) and bridged to the xDai DPOS chain.

        1. DPOS ERC20 staking tokens

          DPOS tokens exist on the Ethereum mainnet as ERC20 tokens. There is a finite supply of these tokens available, the exact supply and method to acquire them is TBD. Once acquired users can transfer their tokens to the xDai DPOS chain using the ERC20-to-ERC20 bridge. There is an entrance fee associated with this transfer and the DPOS ERC20 tokens are converted to DPOS ERC677 tokens. These tokens are then placed as stakes, as detailed below. Block rewards are paid in staking tokens, based on an annual inflation rate that occurs only on the xDai DPOS chain. This means the total supply of DPOS ERC677 might differ from the total supply of DPOS ERC20 on the mainnet when DPOS on the mainnet is not mintable.

        2. Initial validator stakes

          To place a stake, the validator must have at least CANDIDATE_MIN_STAKE (see the StakingAuRa.getCandidateMinStake getter) tokens on the ERC balance of its staking address. This address must also have a balance of native coins to pay for gas costs. To get the staking tokens tokens from Ethereum mainnet (foreign network), the validator uses the

          ERC20-to-ERC20 bridge. To get native coins, the validator uses the ERC20-to-Native bridge to transfer ERC20 DAI tokens from the foreign network to the home network.

          After the tokens and native coins are received from the foreign network using the bridges, the initial validator calls the StakingAuRa.stake function from the staking address with a

          non-zero gas price. The validator passes their staking address and staking amount (greater

          than or equal to the CANDIDATE_MIN_STAKE) as parameters.

        3. Candidate stakes

          A new candidate must:

          1. Acquire tokens and native coins from the foreign network.
          2. Launch their Parity node.
          3. Call StakingAuRa.addPool from their staking address and pass the staking amount (>= CANDIDATE_MIN_STAKE) and their mining address as parameters. The StakingAuRa.addPool function is similar to StakingAuRa.staking but is only for candidates.
        4. Delegator stakes

          A delegator must:

          1. Acquire tokens and native coins from the foreign network.
          2. Call the StakingAuRa.stake function and pass the staking address of the validator/candidate they would like to place their stake on, and the staking amount which is greater than or equal to DELEGATOR_MIN_STAKE (see the StakingAuRa.getDelegatorMinStake getter).
        5. Staking window

          The StakingAuRa.stake and StakingAuRa.addPool functions can only be called if the StakingAuRa.areStakeAndWithdrawAllowed getter returns true. This getter defines the window inside the staking epoch, during which staking and withdrawing can be performed by the participants. For AuRa, this window begins right after the new validator set is applied by the engine (ValidatorSetAuRa.finalizeChange is called) and ends at the last blocks of a staking epoch when a disallow period begins (the disallow period duration is defined by StakingAuRa.stakeWithdrawDisallowPeriod).

        6. Helpful StakingAuRa getters
  • StakingAuRa.stakeAmountthe total staked amount for a specified pool made by the specified address.

  • StakingAuRa.stakeAmountTotalthe total staked amount for a specified pool made by all delegators and the specified staking address.

  • StakingAuRa.getPoolsthe list of active pools (list of staking addresses of candidates and validators).

  • StakingAuRa.poolDelegatorsthe list of current delegators of a specified pool.

      1. New staking epoch, validator selection, and finalizing changes

        During each staking epoch, participants can call these functions:

        • StakingAuRa.stake: to place stakes;

          • StakingAuRa.addPool:to create a new pool;

          • StakingAuRa.withdraw & StakingAuRa.orderWithdraw: to withdraw stakes;

          • StakingAuRa.moveStake: to move stakes.

          On the last block of the staking epoch, the BlockRewardAuRa.reward function calls the

          ValidatorSetAuRa.newValidatorSet function. This function:

          • analyzes the staked amounts on the current pools (candidates and validators);
          • selects new validators;
          • writes the list of new validators (validator set) into the pending list;
          • writes the pending list into the queue which is then read by the

            ValidatorSetAuRa.emitInitiateChange function;

          • increments the staking epoch number which is returned by

            StakingAuRa.stakingEpoch getter;

          • resets the number of the validator set apply block which is returned by the

            ValidatorSetAuRa.validatorSetApplyBlock getter.

            If the total number of candidates and validators is less than or equal to MAX_VALIDATORS, they will all become validators on the next staking epoch. Otherwise, the validators are selected based on a random value and weighted by their pool sizes (the larger the pool, the more likely the candidate becomes a validator). The random seed is taken from the RandomAuRa contract which is described below.

            The pending list of new validators (their mining addresses) can be read by the

            ValidatorSetAuRa.getPendingValidators getter.

            The validator set cannot be changed immediately because the InitiateChange event must be emitted (see the Parity Wiki) prior to this change, so the pending validator set is queued to be handled later by the ValidatorSetAuRa.emitInitiateChange and ValidatorSetAuRa.finalizeChange functions.

            The ValidatorSetAuRa.finalizeChange function is only called for one InitiateChange event. If there are several such events, finalizeChange is called only once for the first emitted event (and the additional InitiateChange events are ignored). So, we can’t emit the next InitiateChange unless the previous event is not finalized.

            For this reason, there is a queue of validator sets used by the ValidatorSetAuRa.emitInitiateChange function. When the ValidatorSetAuRa.emitInitiateChangeCallable getter returns true, a validator’s node calls ValidatorSetAuRa.emitInitiateChange which dequeues the pending validator set and emits the InitiateChange event to let the validators’ nodes know that the set of validators should be changed (see the Parity Wiki).

            When the InitiateChange event is emitted, the ValidatorSetAuRa.emitInitiateChange function sets the initiateChangeAllowed boolean flag to false so that the ValidatorSetAuRa.emitInitiateChangeCallable getter returns false until ValidatorSetAuRa.finalizeChange is called by the engine.

            After applying the new validator set, the engine calls the ValidatorSetAuRa.finalizeChange function to let the ValidatorSetAuRa contract know that the queued pending validator set must be written to the current validator set which is returned by the ValidatorSetAuRa.getValidators getter.

            At this point, the ValidatorSetAuRa.finalizeChange function:

          • replaces the current validator set with the queued validator set;
          • saves the snapshot of the staked amounts made during the previous staking epoch;
          • sets validatorSetApplyBlock to the current block number;
          • sets the initiateChangeAllowed boolean flag to true.

          The ValidatorSetAuRa.validatorSetApplyBlock getter is used to determine the block number where the current validator set was applied by the engine. If this getter returns 0, it means the new staking epoch is started (ValidatorSetAuRa.newValidatorSet is called) but the new validator set is not yet applied by the engine. Stakes and withdrawals are not allowed during this period (see the StakingAuRa.areStakeAndWithdrawAllowed getter).

      2. Validator set changes and validator set queue

        The validator set is always evaluated at the end of a staking epoch, however, it can also be changed during a staking epoch if a validator needs to be removed due to misbehavior.

        In such cases the malicious validator is removed from the validator set (see the internal ValidatorSetAuRa._removeMaliciousValidatorAuRa function) and the new pending validator set is queued to be handled later by the ValidatorSetAuRa.emitInitiateChange and ValidatorSetAuRa.finalizeChange functions.

        As with staking epoch validator set changes, the ValidatorSetAuRa.finalizeChange

        function is used to finalize the validator set change when the malicious validator is removed.

        The validator sets queue is used to finalize different validator sets one after another. This may be required when a malicious validator is removed and the new staking epoch begins immediately after the removal, or when one malicious validator is removed at block number N, but another malicious validator is removed on the next block N+1. Without a queue, such cases would be handled incorrectly because some of the corresponding InitiateChange events would be ignored by the engine (as mentioned above).

      3. Random seed accumulation

        When the number of pools (validators + candidates) is more than MAX_VALIDATORS, a random seed is used to select MAX_VALIDATORS validators for a new staking epoch (see the ValidatorSetBase._newValidatorSet internal function).

        The random seed is stored in the RandomAuRa contract (see the RandomBase.getCurrentSeed getter) and generated in the RANDAO manner: there are several collection rounds per staking epoch, each of which is split into two equal phases – a commits phase and reveals phase:

        1. Commits phase: Each validator node generates its secret number on each phase and calls the RandomAuRa.commitHash function to commit the hash of the secret (one time per each commits phase).
        2. Reveals phase: Each node passes its secret to the RandomAuRa.revealSecret function (once per each reveals phase). The RandomAuRa.revealSecret function XORs the revealed secret with the current seed stored in the contract. Entropy is increased every collection round.

        Committing/revealing the secret is mandatory for each validator. These functions are called automatically by each validator’s node from the validator’s mining address (see 9.3).

        The length of a collection round is defined at network startup in the InitializerAuRa

        contract constructor.

        The RandomAuRa.onFinishCollectRound function is called on each block by the BlockRewardAuRa.reward function. At the end of each collection round RandomAuRa.onFinishCollectRound checks whether the validator skipped revealing the secret during the collection round and increments a skip counter if they did.

        On the final collection round of each staking epoch the

        RandomAuRa.onFinishCollectRound function checks each validator to see

        1. if they skipped revealing too often during the current staking epoch or,
        2. if they skipped revealing on the last collection round.

        If either of these are true, the validator is treated as malicious and removed with the

        ValidatorSetAuRa.removeMaliciousValidator function.

        The maximum number of reveal skips is defined in the RandomAuRa.onFinishCollectRound function and depends on the disallow period duration (see the StakingAuRa.stakeWithdrawDisallowPeriod getter) and on the length of collection round (see the RandomAuRa.collectRoundLength getter).

        The final collection round is especially important to check. During the final round, the last validator in the validator set can decide not to reveal their secret to try to influence the outcome in the ValidatorSetBase._newValidatorSet function. For this reason, any validator that doesn’t reveal their secret during the last collection round is treated as malicious and removed from the validator set.

        To prevent this from happening accidentally due to disconnection, it is recommended that each validator run two separate nodes simultaneously with different internet connections. The first node must have the engine_signer option in a configuration toml file, the second node should not have that option but should have the watchguard script which detects if the first node goes offline and sets the engine_signer option for the second node (see https://github.com/poanetwork/posdao-test-setup/issues/39).

        Since a new validator set can be applied by the engine at any time (e.g. in the middle of some commits/reveals phase), there can be a case when the new validators can’t fully commit/reveal their secrets at the very beginning of the staking epoch. Because of this, there is a short grace period after the new validator set is applied during which the skip counter is not incremented if a reveal is skipped (see the code of RandomAuRa.onFinishCollectRound function).

        RandomAuRa.commitHash and RandomAuRa.revealSecret are called with a zero gas price. This is enabled because the validators’ mining addresses can have zero balances.

        To protect the network against possible spamming by a malicious validator calling the RandomAuRa functions with zero gas price too often, there is a protection mechanism implemented in the TxPermission.allowedTxTypes function: it doesn’t allow creating the RandomAuRa transactions unless they are permitted on the current block (see the RandomAuRa.commitHashCallable and RandomAuRa.revealSecretCallable getters).

        The TxPermission.allowedTxTypes getter is called by the Parity node every time a new transaction is about to be added to a block. This getter checks if the transaction can be included into the block or not.

      4. Removing malicious validators

        There are two cases when a validator can be removed due to misbehavior:

        1. by the RandomAuRa contract due to not revealing secret numbers (see above);
        2. by the ValidatorSetAuRa.reportMalicious function (see the Parity Wiki).

        The ValidatorSetAuRa.reportMalicious function can be called by validators to report a specified validator’s misbehavior on a specified block number. If more than 50% of validators report about the same validator for the same block, the validator is removed from the validator set (see the code of the ValidatorSetAuRa.reportMalicious function).

        The validators’ nodes call ValidatorSetAuRa.reportMalicious with a zero gas price. This is enabled because the validators’ mining addresses can have zero balances.

        To protect the network against possible spamming by a malicious validator calling the ValidatorSetAuRa.reportMalicious function with a zero gas price too often, there is a protection mechanism implemented in the TxPermission.allowedTxTypes function: it doesn’t allow creation of the ValidatorSetAuRa.reportMalicious transaction unless it is permitted on the current block (see the ValidatorSetAuRa.reportMaliciousCallable getter).

        Moreover, if some validator calls ValidatorSetAuRa.reportMalicious too often (much more often than others), such a validator is also treated as malicious (see ValidatorSetAuRa.reportMaliciousCallable and ValidatorSetAuRa.reportMalicious).

        The validator removal process is implemented in the ValidatorSetBase._removeMaliciousValidator internal function. It is called by ValidatorSetAuRa._removeMaliciousValidatorAuRa. When the validator is removed, their mining address is banned for the BAN_PERIOD. This means that the banned validator and their delegators cannot withdraw their stakes until the BAN_PERIOD expires (see the StakingBase._isWithdrawAllowed internal function). Also, the banned mining address cannot be added into the validator set during that period.

        When the validator is removed from the current validator set, the new pending validator set is queued and waits to be passed to the InitiateChange event (see 9.2.4).

        Helpful public getters:

        • ValidatorSetAuRa.isValidatorBanned: check if a specified mining address is banned;

          • ValidatorSetAuRa.banCounter: read the ban counter, which is incremented when a validator is banned;

          • ValidatorSetAuRa.bannedUntil: view the block number when a mining address is released from the ban.

          In a test network, it is possible to set one validator that is not removable (see 9.2.11). Such a validator cannot be removed from the validator set even due to misbehavior (see ValidatorSetBase._removeMaliciousValidator and the section about the unremovable validator below). This feature prevents test network shutdown if there is a problem with the validator set (for example if all validators leave the network simultaneously).

      5. Block reward distribution

        The block reward is distributed among validators and their delegators by the BlockRewardAuRa.reward function. This function is called by the engine when closing each block.

        The pool reward distribution logic is implemented in the BlockRewardBase._distributePoolReward internal function. The pool reward is calculated based on the formulas and stake amounts automatically snapshotted at the beginning of the staking epoch (see the BlockRewardAuRa.setSnapshot called by ValidatorSetAuRa.finalizeChange). Changes in stake amounts during the staking epoch do not affect the pool reward during that epoch, but they do affect the future rewards collected on the next staking epoch.

        There are several kinds of block rewards available for distribution:

        • the ERC20-to-Native bridge fee;
        • the ERC20-to-ERC20 or Native-to-ERC20 bridge fee;
        • inflation distribution.
        1. ERC20-to-Native bridge fee distribution

          This distribution occurs on the next block after the bridge passes the fee amount to the BlockRewardAuRa.addBridgeNativeFeeReceivers function. The fee is distributed in native coins (xDai).

          When the bridge passes the fee amount, its value is stored in the contract and read on the next block by the BlockRewardAuRa._distributeBridgeFee internal function. The fee amount is passed into the BlockRewardAuRa._distributeAmount which contains the reward distribution logic. The function returns the lists of addresses and the corresponding amounts. The lists are then returned by the BlockRewardAuRa.reward function to the engine which mints the specified amounts of native coins for the specified addresses.

        2. ERC20-to-ERC20 or Native-to-ERC20 bridge fee distribution

          This distribution occurs on the next block after the bridge passes the fee amount to the BlockRewardAuRa.addBridgeTokenFeeReceivers function. The fee is distributed in ERC staking tokens (DPOS).

          When the bridge passes the fee amount, its value is stored in the contract and read on the next block by the BlockRewardAuRa._distributeBridgeFee internal function. The fee amount is passed into the BlockRewardAuRa._distributeAmount which contains the reward distribution logic. The function returns the lists of addresses and the corresponding amounts and the lists are passed to the mintReward function of the ERC contract.

        3. Inflation distribution

This distribution occurs every block beginning from the second staking epoch. It needs to know the total amount of stakes made into all of the active validators’ pools, so it must wait until these stakes are placed and snapshotted at the beginning of the staking epoch.

The BlockRewardAuRa._distributeInflation internal function is called every block. It reads the total stake amount calculated and snapshotted at the beginning of the staking epoch by the ValidatorSetAuRa.finalizeChange function where the new validator set is applied (see the BlockRewardAuRa.setSnapshot). The given amount is multiplied by a constant so that the inflation is DPOS_INFLATION_RATE percentage per year. Once calculated, the amount is distributed by BlockRewardAuRa._distributeAmount among the validators and their delegators.

      1. Withdrawing stakes

        Any participant can withdraw their stake (or part of it) using the StakingAuRa.withdraw function. The user passes the staking address of the pool and the amount to withdraw from that pool.

        Withdrawals are allowed during the same period of time when stakes are allowed (see 9.2.2).

        The user can withdraw their full stake or a portion of it. In the latter case the user must leave at least DELEGATOR_MIN_STAKE or CANDIDATE_MIN_STAKE (depending on their role) in the pool.

        If the user withdraws from a candidate’s pool which is not yet a validator, they can withdraw their entire stake amount.

        When withdrawing from a validator’s pool, the user can withdraw only the amount which they have staked during the current staking epoch (see StakingAuRa.maxWithdrawAllowed getter) or they can order a withdrawal. That amount will be withdrawn automatically at the end of the staking epoch (see StakingAuRa.performOrderedWithdrawals which is called by BlockRewardAuRa.reward at the beginning of new staking epoch).

        The StakingAuRa.maxWithdrawAllowed getter checks the maximum current allowable withdrawal. If the pool is an active validator, the maximum possible withdrawal amount is calculated based on existing withdrawal orders as well as the amount staked during the current staking epoch.

        The StakingAuRa.maxWithdrawOrderAllowed getter checks the maximum possible withdrawal amount available to order. If the pool is an active validator, the maximum possible withdrawal amount is calculated based on existing withdrawal orders.

        The StakingAuRa.orderWithdraw function orders a withdrawal. The staking address of the pool and the amount to be withdrawn are passed into the function. The ordered withdrawal amounts can also be reduced or cancelled by passing a negative value into the StakingAuRa.orderWithdraw function.

        The StakingAuRa.orderedWithdrawAmount public getter is used to check the current ordered withdrawal amount.

        Withdrawals ordered during the current staking epoch are performed automatically at the beginning of the next staking epoch by the StakingAuRa.performOrderedWithdrawals function. This function is automatically called by BlockRewardAuRa.reward. The withdrawal of ordered amounts is implemented in the StakingBase._performOrderedWithdrawals

        internal function which performs several checks and then calls the withdraw function of the ERC token contract.

      2. Moving stakes

        In addition to withdrawing stakes, a participant can also move their stake (or a portion of their stake) from one pool to another using the StakingAuRa.moveStake function. This prevents the removal of staking tokens from the balance of the StakingAuRa contract when moving from one pool to another. The stake moving functionality is subject to the same rules and limitations implemented for the withdrawal functions above.

      3. Voluntary exit from a validator set

        If a validator wants to exit from the validator set, they can use one of the following methods:

        1. The validator can call the StakingAuRa.removePool function from their staking address. The pool of the validator is removed from the list of active pools by this function, thus this pool won’t take part in forming a new validator set at the beginning of the next staking epoch (see the ValidatorSetBase._newValidatorSet internal function).
        2. The validator can order a withdrawal of their entire stake amount using the StakingAuRa.orderWithdraw function (see 9.2.8). In this case, the validator will have zero balance in their own pool at the beginning of the next staking epoch and the pool will not be selected by the ValidatorSetBase._newValidatorSet internal function.
      4. Unremovable validator

        Optionally, the POSDAO network can have one unremovable validator (recommended for test networks only). This is defined once on network startup through the InitializerAuRa contract (see the _firstValidatorIsUnremovable boolean parameter of the constructor). If the parameter is true, the first initial validator defined in the constructor is unremovable.

        Such a validator cannot be removed from the validator set either by the ValidatorSetBase._newValidatorSet (even if the validator didn’t place any stake for themselves), nor by the ValidatorSetAuRa.reportMalicious function. However, if they want to change their unremovable status, they can call the ValidatorSetAuRa.clearUnremovableValidator function. This function also can be called by the contract’s owner. The ValidatorSetAuRa.clearUnremovableValidator function can only be called once. After it is called, it is not possible to have another unremovable validator.

        The ValidatorSetAuRa.unremovableValidator public getter retrieves the staking address of the unremovable validator. If this getter returns a zero address, there is no unremovable validator in the validator set.

      5. Zero gas price and service transactions

The owner and the current validators are able to make service transactions (regular transactions with zero gas price) from their mining addresses. This is done through the Certifier

contract; its address is written into the Registry contract (see the Parity Wiki). The owner has

already been mentioned in 9.2.1 above.

Initially, the validators don’t have any native coins to pay gas fees when executing transactions (when calling the RandomAuRa.commitHashRandomAuRa.revealSecretValidatorSetAuRa.emitInitiateChange, and ValidatorSetAuRa.reportMalicious functions; see 9.3). For that reason, their mining addresses can call those functions with a zero gas price.

All transactions are controlled by the TxPermission contract: it doesn’t allow creating zero gas price transactions unless they are permitted on the current block (see the TxPermission.allowedTxTypes function). This protects against abusive use of a zero gas price: the service functions mentioned above can only be called when it is permitted, so they cannot be invoked too often to spam the network.

    1. Modified Parity client for AuRa

      In order to launch the POSDAO network with AuRa, the stable Parity version has been modified to work with the POSDAO contracts. Our modified version contains the following differences:

      • Validator nodes automatically take part in random number generation by making calls to the randomness contract. In the commit phase, they generate a random number and publish its hash on the contract. In the reveal phase, they publish the number itself. The final random number is generated from all of the validators’ contributions.
      • Validators call the reportMalicious function (see the Parity Wiki) if they observe other validators not following the protocol.
      • The validator node that creates a block in which the validator set changes, either because a new staking epoch begins or because a malicious validator is about to be removed, automatically emits the InitiateChange event (see the Parity Wiki).
      • The transaction permission contract and its interface were extended, and allowvalidators to make most calls to our governance contracts with a zero gas price, so that the signing address doesn’t need a non-zero balance. That includes all of the above calls. The extended interface now allows filtering not only by sender, contract address and value, but also by gas price and transaction data.
      • We also implemented a mechanism for validators to directly push theirgovernance-related transactions onto blocks they are preparing, so they don’t have to go through the transaction queue first. Some transactions, like malice reports, use bothmechanisms, so that even if a node has been removed from the validator set at the end of a staking epoch, it can still send its reports to others.
      • We increased signature requirements to ⅔ of validators rather than ½ to protect against the cloning attack scenario.
    2. xDai DPOS network parameters

      Constants used in the xDai DPOS reference implementation

      Constant

      Value

      Unit

      MAX_CANDIDATES

      2000

      candidates (including validators)

      MAX_VALIDATORS

      22

      validators

      CANDIDATE_MIN_STAKE

      1

      STAKE_UNITs

      DELEGATOR_MIN_STAKE

      1

      STAKE_UNITs

      STAKE_UNIT

      10**18

      native coin or ERC20 token with 18 decimals

      SYSTEM_ADDRESS

      2**160 – 2

      BAN_PERIOD

      90

      days

      STAKING_EPOCH_PERIOD

      7

      days

      COLLECTION_ROUND_LENGTH

      200

      blocks

      STAKE_WITHDRAW_DISALLOW_PERIOD

      6

      hours

      DPOS_INFLATION_RATE

      1

      annual %

      BRIDGE_ENTRANCE_FEE

      1

      %

      BRIDGE_EXIT_FEE

      1

      %

      Appendix A: DPOS Reward Distribution

      A working version where values can be manually configured is available here. Total sum staked: 45,101.25 Reward in ERC20 per block: 100

      Pool1

      Staked sum

      Reward

      %

      Reward tokens

      image

      Validator

      2000

      30

      10

      Delegator

      1000

      14

      4.666666667

      Delegator

      1000

      14

      4.666666667

      Delegator

      1000

      14

      4.666666667

      Delegator

      1000

      14

      4.666666667

      Delegator

      1000

      14

      4.666666667

      Total:

      7000

      33.33333333

      Delegators:

      5000

      Pool2

      Staked sum

      Reward

      %

      Reward tokens

      image

      Validator

      10000

      30

      10

      Delegator

      100

      0.2491103203

      0.08303677343

      Delegator

      1000

      2.491103203

      0.8303677343

      Delegator

      10000

      24.91103203

      8.303677343

      Delegator

      10000

      24.91103203

      8.303677343

      Delegator

      1000

      2.491103203

      0.8303677343

      Delegator

      6000

      14.94661922

      4.982206406

      Total:

      38100

      33.33333333

      Delegators:

      28100

      Pool3

      Staked sum

      Reward, %

      Reward, tokens

      image

      Validator

      5000

      49.5049505

      16.50165017

      Delegator

      100

      0.990099009

      9

      0.3300330033

      Delegator

      5000

      49.5049505

      16.50165017

      Delegator

      0

      0

      0

      Delegator

      0

      0

      0

      Delegator

      0

      0

      0

      Total:

      10100

      33.33333333

      Delegators:

      5100

      Appendix B: DAI-to-xDai / ERC20-to-Native bridge example scenario

      Assumptions:

      • Validators/delegators are elected and have bridged DPOS tokens
      • Conversion rate is 1 DAI = 1 xDai
      • Bridge entrance fee is 1%, and exit fee is 1%
      • Same consensus validators are active for entrance and exit. If different staking epochs, different validators and delegators may receive entrance/exit fee

        Validator Pool Stakes:

      • Validator Pool 1: Validator 1 has 100 DPOS and 2 delegators have 100 DPOS each (300 total)
      • Validator Pool 2: Validator 2 has 100 DPOS and 1 delegator has 300 (400 total)
      • Validators Pools 3-10 are single entities validators with 200 DPOS each

        A user wants to use the xDai DPOS chain for scalability purposes. They transfer 100 DAI into the xDai DPOS chain.

        1. 100 DAI are sent to the mainnet bridge contract.
        2. 100 DAI are locked in the bridge smart contract.
        3. Bridge entrance fee of 1 xDai native coin is minted on the xDai side and distributed to active validator pools (1 DAI = 1 xDai = 0.1 xDai for each of 10 pools)
        4. The remaining 99 xDai are minted via a smart contract on the xDai side and sent to the user’s address.
        5. User conducts a lot of transactions, ending up with .3 xDai in transaction fees.
          1. Transaction fees are accrued as they occur. They are sent to the validator (only the validator, not the delegators) responsible for sealing the block where the transaction occurred.
          2. When finished, the user wants to return to the mainnet and has 90 xDAI remaining:
            1. 8.7 xDai remains on the xDai DPOS chain, paid to others
            2. .3 xDai went to transaction fees
            3. 1 xDai went to the bridge entrance fee
        6. User exits the xDai DPOS chain. The bridge smart contract on the xDai side extracts exit fee = .9 xDai. Once the fee is extracted, 89.1 xDai are burned.
        7. Bridge exit fee is distributed to active validator pools (.9 xDai= .09 xDai for each of 10 validators’ pools)
        8. 89.1 DAI are unlocked in the contract on the mainnet.

        Total fees extracted:

      • 1 xDai on bridge entrance
      • .9 xDai on bridge exit
      • .3 xDai in transaction fees (for simplicity lets say 4 separate validators participated in these transactions in an equal manner and the gasPrice/gasLimit were equal)

        Validator rewards collected:

      • Validator Pool 1: 0.19 xDai
        • Validator: .0634 xDai (34%) + .075 xDai in transaction fees
        • Delegator 1: .0633 xDai (33%)
        • Delegator 2: .0633 xDai (33%)
      • Validator Pool 2: 0.19 xDai
        • Validator = .057 xDai (30%) + .075 xDai in transaction fees
        • Delegator: .133 xDai (70%)
      • Validator Pool 3 – 4: 0.19 xDai
        • Validator = 0.19 xDai + .075 xDai in transaction fees
      • Validator Pools 5 – 10: 0.19 xDai
        • Validator = 0.19 xDai

          Appendix C: DPOS / ERC20-to-ERC20 bridge example scenario

          Assumptions:

      • Current validators/delegators are elected and have bridged DPOS tokens
      • Annual inflation rate is 1% for DPOS tokens on the xDai DPOS chain only
      • Bridge entrance fee is 1%, and exit fee is 1%
      • Same consensus validators are active for all staking epochs. This is unrealistic, but allows for simplified calculations.
      • The total amount of DPOS ERC677 staked over the month is 18,000, resulting in an additional 15 DPOS ERC677 (1 percent of 18000 tokens divided by 12 months) distributed over the course of 1 month.

        Validator Pool Stakes:

      • Validator Pool 1: Validator 1 has 100 DPOS and 2 delegators have 100 DPOS each (300 total)
      • Validator Pool 2: Validator 2 has 100 DPOS and 1 delegator has 300 (400 total)
      • Validators Pool 3: Validator 3 has 200 DPOS and 0 delegators (new delegator chooses this pool)
      • Validator Pools 4 -10 start as single entities validators with 500 DPOS each.

        A new delegator user wants to join the xDai DPOS chain and stake some tokens! They transfer 100 DPOS to the xDai DPOS chain.

        1. 100 DPOS ERC20 are sent to the mainnet bridge contract.
        2. 100 DPOS ERC20 are locked in the bridge smart contract.
        3. Bridge entrance fee of 1 DPOS ERC677 staking token (1%) is minted on the xDai DPOS side and distributed to active validator pools (1 DPOS ERC20 = 1 DPOS ERC677 = 0.1 DPOS ERC677 for each of 10 pools)
        4. The remaining 99 DPOS ERC677 are minted via a smart contract on the xDai side and sent to the delegator’s address.
        5. The delegator stakes all 99 DPOS on Validator 3’s pool.
          1. The delegator will not receive any rewards for the current staking epoch. However, in the next staking epoch, the validator 3 pool is elected again and the delegator starts accruing rewards.
          2. The delegator remains with the active validator pool 3 for 4 staking epochs (1 month). At the end of the month, the delegator signals for a stake withdraw.
            1. Over the course of the month, 10,000 additional DPOS tokens were subject to entrance/exit fees. (There were probably additional delegatorsand validators added, and validator set changes, but for simplicity in example calculations let’s say the validator/delegator sets remained static). This means 100 DPOS were collected in fees (1%). There are 10 pools, so 10 DPOS were distributed to each validator pool.
            2. Over the course of the month, the inflation rate resulted in 15 additional DPOS distributed as block rewards. Assuming validator sets did not change and all validators participated equally, 1.5 DPOS were distributed to each pool.
            3. For Validator pool 3, the delegator had ~33% stake, and a total of 11.5 tokens were added to the pool. This means the delegator received ~ 3.79 DPOS ERC677 tokens over the course of the month.
        6. The delegator exits the xDai DPOS chain with ~ 102.79 DPOS ERC677 tokens. The bridge smart contract on the xDai side extracts a 1% exit fee = ~ 1.02 DPOS ERC677.102.79 DPOS tokens are burnt and 1.02 DPOS tokens are minted.
        7. The bridge exit fee is distributed to the active validator pools (1.02 DPOS ERC677 =.102 DPOS for each of 10 validators’ pools)
        8. 101.77 (102.79 – 1.02) DPOS ERC20 are unlocked in the contract on the mainnet. This is the delegator’s new balance in DPOS ERC20 tokens.

        Total fees extracted from the delegator:

      • 1 DPOS ERC677 on bridge entrance
      • 1.02 DPOS ERC677 on bridge exit

        Validator pool rewards collected (through 1 month, all are approximate and based on simple assumptions): In this scenario, over the course of 4 staking epochs, each pool has received:

      • 10 DPOS ERC677 as bridge exit/entrance fees
      • 1.5 DPOS ERC677 as token inflation
      • .10 DPOS ERC677 for bridge exit of example delegator

        This results in the following approximate distributions:

      • Validator Pool 1: 11.6 DPOS ERC677
        • Validator: 3.87 DPOS ERC677 (33.4%)○ Delegator 1: 3.865 DPOS ERC677(33.3%)○ Delegator 2: 3.865 DPOS ERC677 (33.3%)
      • Validator Pool 2: 11.6 DPOS ERC677
        • Validator = 3.48 DPOS ERC677 (30%)
  • Delegator: 8.12 DPOS ERC677 (70%)
  • Validator Pool 3: 11.6 DPOS ERC677
    • Validator = 7.81 DPOS ERC677 (66.6%)
    • Delegator: 3.79 DPOS ERC677 (33.3%) – does not include .10 exit fee
  • Validator Pools 4 – 10: 11.6 DPOS ERC677
    • Validator = 11.6 DPOS ERC677

      Appendix D: DPOS modeling

      We modeled behavior of DPOS consensus participants using NetLogo[20] . The model takes several input parameters which constrain randomized steps of the modeling algorithm:

      image

      Basic DPOS parameters:

      • the maximum size of the validator set
      • the maximum allowed amount of candidates
      • the size of the initial validator set
      • the minimum amount of candidate stake (expressed in staking tokens)
      • the block reward (BR, expressed in reward tokens)
      • the minimum validator reward share, in percents
      • other control variables for stepping the model.

Each step of the model represents one staking epoch. The model abstracts away from the

actual duration of a staking epoch. After 56 steps (modeling about a year in real terms assuming week-long staking epochs) we arrived at the following spread of network participants:

  • horizontally with respect to sizes of the staking pools (from 0 for delegators to +infinity)
  • vertically with respect to rewards the participants accrued (0 to +infinity).imageIt is apparent from the network graph that rewards are assigned to candidates (green and red) in greater amounts compared to proper delegators (blue). This is mostly due to the fact that there were more proper delegators (participants that did not become candidates) than candidates.Analysis also revealed that participants were rewarded proportionally to the time they spent on the network:image

    Additional network statistics

    image

    The “participants” chart displays changes through all staking epochs (from 0 to 56) in numbers of all participants (black), delegators (blue), all candidates including current validators (orange), proper candidates excluding current validators (green), and current validators (red).

    The “rewards” chart displays the rewards accrued by participants in each of these categories.

    The “stakes” chart displays the amounts staked by participants in these categories.

    A working model where values can be manually configured is available here.

    Appendix E: Honey Badger BFT (HBBFT) integration

    The Honey Badger BFT (HBBFT) consensus algorithm allows nodes in a distributed, potentially asynchronous environment to achieve agreement on transactions. The agreement process does not require a leader node, tolerates corrupted nodes, and makes progress in adverse network conditions. See the HBBFT github repository for more information.

    We are currently integrating HBBFT with the Parity Ethereum client to provide an additional consensus option for POSDAO. Modifications to Parity include:

  • Block agreement process: HBBFT consensus is reached on a proposed list of transactions before a block is produced. This list is comprised of the union of all (or most) transactions proposed by the acting validators and each validator creates an identical block. The block is signed collaboratively using threshold signatures.

  • RNG generation: HBBFT can create secure randomness from numbers that are only revealed after agreement has been reached on their contents. This randomness can be used to select new validator sets at the beginning of a staking epoch, and as a secure source of randomness for smart contracts.

  • Block validation: Blocks sealed with a threshold signature need to be accepted as valid. Parity must keep track of the current validator set in order to match the threshold signature with the validator set’s master key.

  • Block creation: To increase throughput, new blocks can be created as soon as the transactions for the previous block have been determined, even if the previous block has not yet been sealed.

  • Governance contract interaction: Parity needs to request the validator set to determine validator set changes, then use HBBFT to enact these changes. Parity should also report malicious validator behavior (fault reporting) to contracts.

  • Validator set changes/key generation: Validator sets are transitioned over several blocks, and this process requires a set of threshold keys for the new validators, which must be generated “on-chain” (using a separate smart contract).

  • Networking: To communicate efficiently, nodes must exchange low-latency,

    high-bandwidth targeted messages. When the validator set changes, new validators must establish direct connections to one another.

  • Network startup: Items must be added to the chain specification so they are included in the genesis block. This includes compiled governance contracts and the public master key. In addition, corresponding key shares must be distributed to initial network validators (this may be accomplished outside of the network) prior to network start.

References

[1] de Vries, A (2018). Bitcoin’s growing energy problem. Joule, 2(5), 801-805. https://doi.org/10.1016/j.joule.2018.04.016

[2] J. Siim, “Proof-of-stake”, Research Seminar in Cryptography, 2017. https://courses.cs.ut.ee/MTAT.07.022/2017_fall/uploads/Main/janno-report-f17.pdf

[3] Saleh, F. (2018).区块链 Without Waste: Proof-of-Stake. SSRN Electronic Journal. 10.2139/ssrn.3183935.

[4] Iddo Bentov, Ariel Gabizon, and Alex Mizrahi (2014). 加密货币 without proof of work.

CoRR, abs/1406.5694. https://arxiv.org/pdf/1406.5694.pdf

[5] Buterin, V., and V. Griffith (2017). Casper the Friendly Finality Gadget. CoRR, https://arxiv.org/abs/1710.09437.

[6] AuRa (Authority Round) Consensus Engine https://wiki.parity.io/Aura

[7] Miller, A., Xia, Y., Croman, K., Shi, E., Song, D. (2016). The Honey Badger of BFT Protocols.

In: Cryptology ePrint Archive 2016/199 https://eprint.iacr.org/2016/199.pdf

[8] D. Larimer (2017). DPOS Consensus Algorithm – The Missing White Paper. https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper [9] V. Buterin (2014). A next-generation smart contract and decentralized application platform. https://github.com/ethereum/wiki/wiki/White-Paper

[10] Gazi P., Kiayias A., Russell A. (2018). Stake-Bleeding Attacks on Proof-of-Stake区块链s. 2018 加密货币Valley Conference on区块链 Technology (CVCBT), 85-92. https://allquantor.at/blockchainbib/pdf/gazi2018stake.pdf

[11] “Nothing at stake attack ethereum.” [Online]. Available: https://github.com/ethereum/wiki/wiki/Problems

[12] Li, W., Andreina, S., Bohli, J., Karame, G. (2017). Securing Proof-of-Stake区块链 Protocols. Data Privacy Management, 加密货币 and区块链 Technology. Springer, Cham, 297-315.

https://www.researchgate.net/publication/319647471_Securing_Proof-of-Stake_Blockchain_Pro tocols

[13] Kanjalkar, S., Kuo, J., Yunqi Li, Y. & Miller, A. (2019). Short Paper: I Can’t Believe It’s Not Stake! Resource Exhaustion Attacks on POS. Financial Cryptography 2019. http://fc19.ifca.ai/preproceedings/180-preproceedings.pdf

image

[14] “Fake Stake” attacks on chain-based Proof-of-Stake cryptocurrencies. [Online]. Available: https://medium.com/@dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrenci es-b8b05723f806

[15] Parinya Ekparinya, P., Gramoli, V., Jourjon, G. (2019). The Attack of the Clones against Proof-of-Authority. https://arxiv.org/abs/1902.10244

[16] Parinya Ekparinya, P., Gramoli, V., Jourjon, G. (2018). Impact of Man-In-The-Middle Attacks on Ethereum https://doi.org/10.1109/SRDS.2018.00012

[17] Randao: Verifiable Random Number Generation (2017) [Online]. Available:

https://randao.org/whitepaper/Randao_v0.85_en.pdf

[18] Alturki, M. & Rosu, G. (2018). Statistical Model Checking of RANDAO’s Resilience Against Pre-computed Reveal Strategies. https://www.ideals.illinois.edu/bitstream/handle/2142/102076/rdao-analysis.pdf

[19] GencerA.E.BasuS.EyalI.vaRenesseR.SirerE.(2018)DecentralizatioiBitcoianEthereuNetworkshttps://arxiv.org/pdf/1801.03998.pdf

[20] NetLogo. https://ccl.northwestern.edu/netlogo/

POSDAO

利益去中心化的自治组织证明

作者:Igor Barinov,Vadim Arasev,Andreas Fackler,Vladimir Komendantskiy,Andrew Gross,Alexander Kolotov,Daria Isakova

抽象

在本文中,我们介绍了POSDAO,一种作为去中心化自治组织(DAO)实施的股权证明(POS)算法。它旨在为公共链提供去中心化,公平和节能的共识。该算法用作一组用Solidity编写的智能合约。POSDAO使用通用BFT共识协议实现,例如具有提议者节点和概率最终性的授权回合(AuRa),或具有无领导性和即时终结性的Honey Badger BFT(HBBFT)。激励验证者通过可配置的奖励结构来表现出网络的最佳利益。该算法提供了Sybil控制机制,用于管理一组验证器,分发奖励,以及报告和惩罚恶意验证器。作者提供了参考POSDAO实现,xDai DPOS,它使用xDai作为稳定的交易代币和代表性的ERC20令牌(DPOS)作为赌注令牌。参考实现在以太坊1.0侧链上起作用并利用AuRa共识协议。使用POA代币Bridge的多个实例,在以太坊主网和xDai DPOS网络之间桥接资产。

目录

  1. 简介3

    1. 赌注模型证明4
    2. 委托的股权证明5
    3. 去中心化的自治组织(DAO)5
    4. POSDAO共识模型5
  2. 术语7

  3. 奖励分配8

    1. 可配置的奖励结构9
      1. 交易费9
      2. 桥费9
      3. 固定块奖励9
    2. 奖励分配的三条规则10
    3. 分发实例11
      1. 每个区块的股权池获得相同的奖励11
      2. Validator在池中按比例分配奖励。11
        1. 没有委托人的案例12
        2. 案例有一个委托人和一个验证人12
        3. 多个代理人的案例13
      3. Validator与代理商分享奖励,奖励比例为30%至70%池。14
        1. 案件有一名代表14
        2. 多个代理人的案例15
  4. 验证器组形成15

    1. 网络参与者15
    2. 沉淀时代16
    3. 成为候选人16
    4. 候选人16
    5. 放入和离开股权池16
    6. 移动赌注17
    7. 选择验证器时的随机性18
  5. POSDAO网络初始化18

    1. 桥接网络方案19
      1. 桥1:ERC20到ERC20桥19
        1. ERC20-to-ERC20大桥入口和出口费20
      2. 桥2:ERC20到本地桥225.1.1.1 ERC20到本土桥的入口和出口费用22
      3. 桥设置和初始验证器24
    2. 初始化参数26
      1. 建议27
  6. 理由27

    1. 共识机制27
      1. 共识层选项27
      2. 委托证明(DPOS)28
    2. 奖励结构28
      1. 最低候选人股份28
      2. 块奖励的平等份额28
      3. 比例奖励分配为70/30%28
      4. 双令牌环境29
  7. 不当行为和共识错误管理29

    1. 远程攻击30问题30解决方案30
    2. 没有任何东西攻击30问题30解决方案30
    3. 假股权攻击31问题31解决方案31
    4. 克隆攻击31问题31解决方案32
    5. POSDAO实施特定攻击32
      1. RANDAO攻击32问题32解决方案32
      2. 移除桥攻击33问题33解决方案34
      3. 协调验证器设置攻击34问题34解决方案34
  8. 未来方向34

    1. Honey Badger BFT全面实施34
    2. 桥梁治理发展35
    3. 奖励模型分析35
    4. 抵押35
  9. 参考实施说明35

    1. POSDAO智能合约35
    2. 实施细节37
      1. 网络启动37
      2. 放置赌注38
        1. DPOS ERC20标记令牌39
        2. 初始验证员赌注39
        3. 候选人赌注39
        4. 代表团赌注39
        5. Staking窗口40
        6. 有用的StakingAuRa getters 40
      3. 新的赌注时期,验证器选择和最终确定的变化40
      4. 验证器集更改和验证器集队列42
      5. 随机种子增持42
      6. 删除恶意验证器44
      7. 区块奖励分配45
        1. ERC20-to-Native桥费分配46
        2. ERC20-to-ERC20或Native-to-ERC20桥费分配46
        3. 通货膨胀分布46
      8. 撤回赌注46
      9. 移动赌注48
      10. 自愿移除验证器组48
      11. 不可移除的验证器48
      12. 零天然气价格和服务交易49
    3. AuRa 49的修改后的奇偶校验客户端
    4. xDai DPOS网络参数50

附录A:DPOS奖励分配51

附录B:DAI-to-xDai / ERC20-to-Native网桥示例场景52

附录C:DPOS / ERC20到ERC20网桥示例场景54

附录D:DPOS建模57

其他网络统计58

附录E:Honey Badger BFT(HBBFT)集成59

参考文献60

  1. 介绍

    虽然以太坊2.0(Serenity)将为以太坊生态系统带来股权证明控制和许多其他创新,但完成日期目前尚不清楚。完成后,以太坊1.0将继续提供可行且可用的网络,需要长期支持和优化。POSDAO(股权去中心化自治组织证明)协议为以太坊1.0提供了一种即时可用的可扩展性解决方案,为Staking和委托赌注,非常快速的交易以及非常低的交易成本创造了机会。POSDAO运行在完全兼容的基于EVM的侧链上,允许主网互操作性,同时提供更高的效率,更低的费用,可配置性以及与当前EVM共识实施相关的其他优势。

    除了缓慢而昂贵的交易之外,越来越多的证据表明,中本共识(也称为工作证明)模型从长远来看在生态上是不可行的。比特币目前使用“至少2.55吉瓦的电力”,有可能消耗“未来7.67千兆瓦”,相当于“奥地利(8.2千兆瓦)[1]等国家的总使用量。”因此,更多的区块链网络采用股权证明(POS)和委托证明(DPOS)协议变体作为共识选择[2]。这些协议负责指定处理事务和更新分布式系统中的分类帐的网络节点。它们已被证明可以为区块链提供必要的安全性和共识,并提供比当前Nakamoto实现更高的效率[3]。在POSDAO中,POS算法被实现为去中心化的自治组织(DAO)。

    POS协议的参与者以代币或代币的形式存放资产,以保护网络并就区块链交易达成协议。以太坊生态系统中有许多项目由项目支持者持有项目特定令牌,但这些资产的效用有限。通过将项目特定令牌转换为DPOS标记令牌,令牌持有者可以作为验证者或委托人参与基于以太坊的侧链的共识过程。他们根据参与情况获得奖励(块奖励或交易奖励)。这为代币持有者提供了将任何数量的当前持股转换为赌注代币的机会,这反过来又可以获得基于奖励的股息。

    虽然目前有许多POS和DPOS实施可用,但它们通常具有设定标准,这些标准决定了它们的基本功能并限制了它们的潜在用途。POSDAO链中的参数是高度可配置的。这包括基础共识协议,块奖励功能,事务率,标注规范和其他实现细节。

    参考实现提供了可以根据链的目的和用户需求而改变的设置和参数。

    1. 股权证明模型

      共识算法为诚实的协议执行和去中心化提供了经济激励。证明(POS)模型[4]中,个人投入一定数量的令牌以努力被选为块生产者(验证者)。验证者的选择基于众多标准; 通常,在选择过程中使用桩的数量和随机信标。作为成功创建块的交易所,验证器将获得额外的令牌。

      与工作证明(POW)模型相比,POS Sybil抗性系统的主要优点是减少了能量消耗。此外,POS可以激励验证者运行高带宽节点和备份节点以实现冗余,从而提高网络吞吐量。另一方面,战俘鼓励购买更多的挖矿硬件,这不会提高最大吞吐量。

      有两种主要的POS模型:基于链的股权证明,其中“[…]具有一系列区块,通过伪随机分配向利益相关者创建新区块的权利来模拟挖矿,以及拜占庭容错(BFT)股权证明,现有的BFT共识被用于Sybil控制和经济激励模型“ [5]。POSDAO利用智能合约进行验证器选择过程。然后,这些验证器集运行基础共识协议。它可以配置为使用Parity的AuRa共识引擎[6] 或Honey Badger BFT [7]

    2. 委托证明

      委托的股权证明(DPOS)[8]扩展了POS模型,允许其他人将他们的代币放在潜在的验证人(候选人)上,而不参与自己的区块生产。收集更高比例的代币的候选人在网络上成为验证者的可能性更大。然后将奖励分为验证者和赌注实体(委托人)。

      DPOS为代理人提供了通过在其上放置令牌来“投票”潜在验证人的机会。鼓励候选人保持良好的声誉,以吸引更多的代表,并增加他们成为验证人的机会。POSDAO旨在支持DPOS模型。

    3. 去中心化的自治组织(DAO)

      DAO是一个自我维持的虚拟实体,由“包含资产并编码整个组织的章程的智能合约”定义。[9] “所有金融交易,规则和决策都在区块链中制定并存储,创建了透明且可验证的记录。规则最初在智能合约中规定,成员(参与令牌持有者)根据这些规定进行互动,以进一步实现组织的目标。组织规则可以通过链内合约中包含的机制或通过主链解决方案和/或软件更新等链外治理流程进行修改。

    4. POSDAO共识模型

      POSDAO共识实现了一个分层的POS模型,该模型通过公共区块链上的智能合约连接(参见下面的图1)。在EVM中工作的智能合约中存在Sybil控制和激励,执行状态存储在实现POSDAO共识的公共链上。基础BFT共识存在于网络协议级别。该模型需要修改以太坊客户端中的BFT一致性算法实现,以促进智能合约与共识层之间的信息交易所。这包括有关共识故障和验证器集管理的通信中继。

      请注意,POSDAO的AuRa实现将首先完成,HBBFT将在未来版本中实现。

      图片

      图1:POSDAO中参与者与主要共识合约之间的相互作用。

  2. 术语

    术语

    数学符号

    定义

    Staking单位

    1μ ∈ 中号

    = {ETH,DAI,POA …}

    算法的参与者用于Staking的标记面额。演员包括候选人,验证人和委托人。

    最低候选人股份

    ST Ç =一个μ

    – 多个赌注单位

    作为验证器插槽候选者所需的最小赌注单位数量。

    候选人的股份

    ST Ç =一个μST Ç ST Ç

    – 多个赌注单位

    给定候选人的赌注单位数量。如果候选人被选为验证者,则候选人权益被称为验证者股份而不改变符号。

    最低代理人股份

    ST =μ

    – 多个赌注单位

    作为委托人参与池所需的最小赌注单位数量。

    代表人的股份

    ST =μ

    一世

    DD

    ST  ST 分钟

    – 多个赌注单位

    i个委托人为特定池贡献的赌注单位数量。

    候选人

    以太坊地址,至少存放最小候选股份以形成新池。

    委托者

    以太坊地址,用于将赌注单位分配给候选人/验证人的池。代表和候选人/验证人一起形成了池的流动性。

    st

    ñ

     ST + ST Ç

    st i

    = 1

    分配给候选/验证者的赌注单位总和。这包括所有代理人的赌注单位以及由候选人/验证人赌注的单位。桩的比例用于确定池奖励分配。

    验证器

    由算法选择的候选者参与用于铆接时期的验证器集。

    验证器集

    为一个赌注时期选择的一组验证器,以保持网络的共识。每个验证器代表验证器的池。

    初始验证人

    网络初始化期间定义的验证器集。

    赌注时代

    Ť

    选择验证器集的持续时间(以AuRa为单位,以HBBFT表示的时间)。例如,对于具有5秒块时间(对于AuRa)的一周时间帧,将其设置为120960。

    池奖励

    RW

    rw = BR 1

    Ĵ

    ñ

    =Σ [R d + [R V

    一世

    = 1

    – 验证器的数量

    n – 委托人数验证人的奖励委托人的奖励

    池中验证者和委托人的奖励代币的块奖励。它们之间的分配在 3.奖励 分配中定义

    区块奖励

    BR

    每个块拨出的奖励代币总数(或者像Honey Badger BFT这样的共识算法的每个时间量)。无线电通信局均匀分布在所有参与的验证池中。

    奖励令牌

    Ť

    用于奖励验证者和委托人的ERC20或本地令牌。

    图片

  3. 奖励分配

    奖励分配是算法的主要激励机制。在本节中,我们将根据其贡献金额解释池中验证者和委托者之间的奖励分配规则。

    POSDAO提供了实现双令牌环境的选项。这不是算法的要求,但允许有机会探索各种经济激励。在参考实现中,DPOS ERC20令牌 – 桥接为ERC677表示 – 用于Staking。它还用于从ERC20到ERC20桥接器提供令牌奖励

    (出入境费)和积分奖励。第二个令牌(本地稳定代币)用于交易费用(仅支付给验证者)和ERC20到ERC20桥梁的奖励(入口/出口费用)。

    块奖励是可配置的,可以根据实现的要求进行设置。在参考实施中,块奖励仅通过应用于侧链DPOS标桩令牌的1%年度通货膨胀度量来支付(有关更多参考实施细节,请参见9.2.2)。

    额外奖励通过交易费用(仅限验证人)和入口/出口费(针对验证人及其代理人)确定(见5.1)。

    1. 可配置的奖励结构

      可以使用POSDAO算法实现以下奖励类型。

      1. 交易费用

        每个链上交易都被评估为交易(燃气)费用。此费用是可配置的,默认值非常低。密封块的验证器(在AuRa实现中)收集与该块相关的任何交易费用。在HBBFT中,费用将在验证人之间平均分配。此奖励不会分发给池中的代理人,而只会授予验证人。

      2. 桥费

        如果在实施中使用桥梁,则可以在链条之间转移资产时评估桥梁费用(详见5.1)。当资产从以太坊主网转移到侧链时收取入场费,并在资产移回主网时评估移除费。费用根据其赌注比率分配给验证人和代理人(见3.2)。

      3. 固定块奖励

        当产生新块时,协议将活动验证器列表传递给奖励分配功能。奖励功能为所有活动验证器及其委托人提供奖励令牌(或原生代币,具体取决于网络设置和桥接模式)。如果验证者未参与共识过程(由于行为不当),则其池不包括在奖励分配中。

        为了计算块奖励,总赌注金额(从赌注时期的开始计算)乘以常数(通货膨胀率)并在验证者及其委托人之间分配。有关基于参考实现的更多详细信息,请参见9.2.7

        图片

        图2:在此示例中,交易费仅授予验证者,并且桥接费和块奖励在节点验证器和相关委托者之间分配。

    2. 奖励分配的三条规则

      为了保持公平和激励当选的验证人,奖励分配根据以下规则计算:

      1. 验证器集内的每个池在块创建时获得块奖励的相等份额。
      2. 只要总代理人的股权比例低于70%,池奖励就会在验证人和注册代理人之间按比例分配。
      3. 验证者保证至少获得30%的池奖励。如果总代理人的比例超过70%,则代理人的奖励将相应调整,验证人将获得30%的奖励。注意:此参数是可配置的,我们将进行统计分析以确定其在我们的参考实现中的功效。

      有关详细示例,请参阅附录A.

    3. 分发示例

      1. 股权池每个区块获得相同的奖励

        让我们介绍每个区块的股权池奖励。我们假设它是在网络启动时定义的。

        图片

        区块奖励1奖励令牌

        如果在给定的Staking时期内验证器中心化有一个验证器,则该验证器的池将获得100%的块奖励。

        ID

        池奖励

        验证员A.

        100%的块奖励

        让我们假设最小候选赌注是一个赌注令牌,最小授权赌注是0.01赌注令牌。

        最低候选人股份

        1个赌注令牌

        最低授权股份

        0.01赌注令牌

        如果每个给定的staking时期验证器中心化有两个验证器,即使它们的池有一个

        不同数量的赌注令牌st A = / st B 

        奖励。

        ,每个池将收到50%的块

        ID

        赌注令牌数量

        池奖励

        验证员A.

        1

        50%的积分奖励

        验证员B.

        2

        50%的积分奖励

      2. Validator在池中按比例分配奖励。

        当代理人赌注的总金额的份额小于或等于池的70%时,奖励按比例分配给参与者。

        ñ

        d

        Σ ST 

        = 1

        st

        ≤0.7

        ST

        d

        图片

        [R

        P

        一世

        rw i

        ST

        V

        st C.

        P

        = P rw *

        ST

        1. 没有委托人的情况

          验证者拥有100%的池奖励。

          赌注令牌

          池奖励,%

          图片

          图1 :没有委托人的单个验证者的奖励分配

          1

          100

          蓝色验证器

          1

          100

        2. 案例有一个委托人和一个验证人

          委托人承担的金额少于池内赌注金额的70%。委托人与验证人按比例分享池奖励。

          赌注令牌

          池奖励,%

          图片

          图2 :当委托人的赌注少于池的70%时,单个委托人的单一验证人的奖励分配

          1.25

          100

          蓝色验证器

          1

          80

          红色代表

          0.25

          20

        3. 有多个委托人的案例

          在这种情况下,所有委托人的赌注总和不到池中赌注总金额的70%。该小组与验证人按比例分享奖励。

          赌注令牌

          池奖励,%

          图片

          图3 :当所有委托人的赌注总和时,具有多个委托人的单个验证人的集合奖励分配

          不到70%的股权池。

          1.25

          100

          蓝色验证器

          1

          80

          红色代表1

          0.05

          4

          绿色代表2

          0.1

          8

          黄色代表3

          0.1

          8

      3. 验证员与代理商分享奖励,其比例为30%至70%。

        当委托人赌注的总金额超过集合的70%时,委托人的奖励份额上限为70%。

        ñ

        d

        Σ ST 

        = 1

        st

        > 0.7

        验证者的奖励从未在股权池中降至30%以下。这可以确保节点被激励为验证器本身,而不仅仅是委托。

        d

        [R

        一世

        = 70% * rw *

        st i

        图片

        ñ

        d

        = 30%

        rw

        Σ ST 

        = 1

        1. 案件有一名代理人

          一名代表投了超过70%的股权池。验证人的池奖励仍为30%。委托人获得70%的股权池奖励。

          赌注令牌

          池奖励,%

          图片

          图4 :具有单个委托者的单个验证器的奖励分配

          委托人的赌注超过了70%

          4

          100

          蓝色验证器

          1

          三十

          红色代表

          3

          70

        2. 有多个委托人的案例

          多个代理人的赌注总额超过了股权池的70%。验证者的池奖励不会低于30%。代表们按比例分享70%的奖池。

          赌注令牌

          池奖励,%

          图片

          图5 :当所有委托人的赌注总和超过池的70%时,具有多个委托人的单个验证人的池奖励分布

          6

          100

          蓝色验证器

          1

          三十

          红色代表1

          2

          28

          黄色代表2

          3

          42

  4. 验证器集合形成

    具有最低所需候选人赌注的任何地址都可以成为验证者。当一个地址调用addPool合约函数并满足最低要求的候选赌注时,它将成为候选者并形成一个新的池。

    1. 网络参与者

      网络参与者的数量是可配置的,不能超过分配给MAX_CANDIDATES和MAX_VALIDATORS参数的值。

      参与的代表人数没有限制。任何至少具有DELEGATOR_MIN_STAKE标记(ERC20或同等标记)的任意地址都可以使用其标记并成为委托人。

    2. 铸造时代

      网络的操作分为堆积时期(STAKING_EPOCH_PERIOD – 此值可配置,默认为一周周期)。在前一个纪元终止后立即开始新的铆接时期。

      在每个堆积时期的开始,算法从当前候选列表中选择新的验证器集,并创建验证器池的当前状态的快照。如果候选者少于MAX_VALIDATORS,则每个候选者都成为验证者。快照用于计算每个Staking时期内验证者和委托者的奖励分布。

    3. 成为候选人

      网络中的任意地址A启动其节点,并在其自己的地址上至少放置ERC20兼容的标记令牌(CANDIDATE_MIN_STAKE)中的最小权益。然后,地址A使用addPool函数将地址B指定为挖矿地址。为地址A创建新的活动池,此帐户将成为候选帐户。

      • 地址A是用于收集奖励并将赌注放入其自己的池中的赌注地址。
      • 验证器节点使用地址B对块进行签名,参与随机信标(见4.7),并报告恶意验证器。
    4. 候选人股权池

      在每个铆接时期的开始,算法选择活动候选池作为验证器参与下一个验证器集。非活动池将被忽略。

      如果候选人从其池中撤回所有令牌,则该池将变为非活动状态,并且不参与下一个验证器选择过程。候选人可以完全撤回他们的代币并将自己移除为池,或者部分移除他们的代币(假设他们离开CANDIDATE_MIN_STAKE)并参与后来的赌注时期。

    5. 放大和移除股权池

      在大多数赌注时期,参与者可以将赌注存入或撤出池中。例外是每个时代结束时的定义时期

      (STAKE_WITHDRAW_DISALLOW_PERIOD)。这一措施可以根据时代末期产生的随机种子值来防止赌注操纵(见4.7)。

      • 候选人或验证人在自己的股权池中的总赌注金额不得低于CANDIDATE_MIN_STAKE。
      • 任何池中委托人的总赌注金额不得低于DELEGATOR_MIN_STAKE。

      最低候选人股份相对较大,鼓励机构投资者成为候选人和验证人。这一大量股权为候选人保护其节点和防止DoS攻击创造了额外的激励。但是,仍然可以对各个验证器节点进行DoS攻击。验证者的部分工作是通过使用提供DoS保护的ISP来抵御此类攻击。

      在当前铆接时期(从而改变池的大小)期间额外的令牌Staking或从池中撤出不会影响当前池奖励。奖励是根据赌注时期开始时池的状态确定的(见4.2)。

      但是,这些变化将影响以下铆接时期的验证器选择概率。

      参与者不能从活动验证器的池中提取其令牌,除非该金额在当前的赌注时期被搁置(此金额尚未被分配为赌注,因此可以撤回)。可以随时从候选人的池中撤回令牌(因为候选人不是验证者)。

      如果参与者(委托人或验证者)想要离开活动验证者的池或减少其赌注金额,他们可以安排从池中移除。在下一个赌注时期开始时,所选金额将自动提取到参与者的地址(或者如果参与者是验证者,则返回到验证者的赌注地址)。

      如果验证者想要在下一个赌注时期终止其验证者状态,他们可以安排撤回其赌注金额或调用合约的removePool函数(在这种情况下,池变为非活动状态,并且算法在开始时不会选择下一个赌注时代)。

    6. 移动赌注

      参与者(代理人或候选人)可以将其全部或部分股权金额从一个池转移到另一个池,而无需从合约中提取金额。这样的举动受到上述相同的提款规则的约束。

    7. 选择验证器时的随机性

      该协议实现了类似于RANDAO的随机数发生器,其用于在每个铆接时期开始时从候选组中随机选择一组验证器。具有较大池的候选者具有较高的选择到每个铆接时期的验证器集的概率(具有较高赌注的候选者被概率地选择为更多铆接时期的验证器)。

      图片

      图3:验证器集选择由验证器/候选池大小和随机值确定。

  5. POSDAO网络初始化

    POSDAO智能合约在创世块中初始化。它们的预配置参数包含在字节码中,初始验证器集也在这些参数中定义。

    网络从创世块开始。在参考实现中,网络中的所有地址(包括初始验证器)具有零余额。初始验证器没有预先初始化的赌注,因此它们的池也是空的。

    POSDAO可以配置为独立区块链运行。它还可以使用连接到一个或多个其他网络的网桥运行。该桥接场景用于参考实现中,并在下面描述。

    1. 桥接网络方案

      POA代币Bridge用于连接以太坊链实例,允许用户在链之间传输资产。在参考实现中,两个POA代币Bridge实例将POSDAO侧链网络连接到以太坊主网。

      两个桥都有自己的验证器集,它们不与POSDAO网络中设置的共识验证器绑定。桥接验证器负责链之间的安全令牌传输,并且它们不会获得此服务的任何奖励。

      图片

      图4:以太坊主网和xDai DPOS网络之间的参考实现桥接。

      1. 桥1:ERC20到ERC20桥

        第一个桥接实例在ERC20到ERC20模式下运行,将POSDAO网络与以太坊主网络连接起来。这允许参与者将他们的赌注令牌(参考实现中的DPOS ERC20令牌)从主网络桥接到POSDAO

        网络(并在需要时将它们从POSDAO移回主网)。有关示例方案,请参阅附录C.

        图片

        图5:使用ERC20到ERC20桥的链之间的令牌传输。请注意,ERC677是ERC20扩展,可以轻松进行传输操作。

        1. ERC20-to-ERC20桥入口和出口费

          当令牌在两个网络之间移动时,评估入场费和出境费。这些资金分配给验证人员池,以提供赌注奖励。这些值是可配置的(请参阅9.4中的BRIDGE_ENTRANCE_FEE和BRIDGE_EXIT_FEE常量),在此示例中,它设置为总桥接事务令牌值的1%。

          图片

          图片

          图6-7:桥入口和出口费用分配到活动验证器池。

      2. 桥2:ERC20到本地桥

        第二个桥接实例使用ERC20到Native模式运行。在这种情况下,参与者将他们的ERC20令牌从以太坊主网桥连接到支持POSDAO的侧链(并根据需要将代币移回主网)。在参考实现中,我们使用DAI作为ERC20令牌,使用xDai作为Native令牌。

        图片

        图8:使用ERC20-to-Native网桥在链之间进行令牌传输。

        5.1.1.1 ERC20到本土桥的入口和出口费用

        当在两个网络之间锁定/解锁和铸造/烧毁令牌时,还评估入口和出口费用。这些资金也分发给验证人员池,以提供赌注奖励。该值是可配置的,在此示例中,它设置为令牌 – 代币转移金额的1%。有关示例方案,请参阅附录B.

        图片

        图片

        图9-10:桥入口和出口费用分配给活动验证器池

        5.1.3网桥设置和初始验证器

        在POSDAO网络启动后,ERC20到ERC20网桥在第一个Staking时期内连接并初始化。一旦桥接器连接,初始的一致性验证器(在ValidatorSet智能合约中定义)可以将他们的DPOS ERC20令牌从以太坊主网络桥接到POSDAO网络,并将赌注放入他们自己的池中。

        因为验证器在网络启动时没有本机代币(在我们的示例实现中为xDai),所以它们可以使用零气体对POSDAO合约进行服务交易。

        验证者可以进行无限制的服务交易,但仅限于共识合约的范围内。该TxPermission智能合约防止从一个验证发送可能是垃圾。图11显示了一个示例网络初始化。

        如果初始铆接时期结束并且没有候选者(初始验证器都没有进入其池中),则初始验证器集将保留用于随后的铆接时期。

        但是,如果出现至少一个候选者(向其池中添加桩号的地址),则从该组中移除具有空池的任何初始验证器,并且该候选者成为新的堆积时期的验证器。因此,如果初始验证者想要在最初的赌注时期之后保留他们的座位,他们必须将赌注放入他们自己的池中。

        在连接桥之后,个人可以桥接他们的DPOS令牌并成为POSDAO网络中的候选者。图12显示了候选人地址的各种可能的交互。

        如果在新的铆接时期开始时候选者的数量大于MAX_VALIDATORS,则从候选者集合中随机选择(使用随机信标)验证者:候选者的池越大,候选者成为验证者的概率越高。 。

        图片

        图11:初始化三个初始验证器和一个候选者(这里不使用随机因为初始验证器+候选者的数量≤22):

        图片

        图12:来自单个以太坊地址的候选人互动。

        5.2初始化参数

        当新网络启动时,将填充初始验证器集。初始验证器的数量等于初始候选者的数量。

        网络启动时的初始参数示例:

        候选人人数

        三十

        验证器数量

        4

        委派人数

        0

        初始验证人1(挖矿地址)

        0X …

        初始验证器1(Staking地址)

        0X …

        初始验证人2(挖矿地址)

        0X …

        初始验证器2(Staking地址)

        0X …

        初始验证人3(挖矿地址)

        0X …

        初始验证器3(Staking地址)

        0X …

        初始所有者

        0X …

        除了初始验证器之外,所有者还部署桥接合约,并且能够在需要时升级桥接和共识合约(例如,如果发现错误或需要修改代码)。所有者应该是MultiSig智能合约,需要可信任的设置。此设置的详细信息可能因网络的性质而异。未来的实施可能包括投票机制,以使验证者能够对升级进行投票。这将减轻对所有者合约的需求。

        5.2.1建议

        配置验证器的数量时,应考虑基础的一致性算法。例如,我们的AuRa变体和HBBFT都可以容忍最多和不包括三分之一的验证器发生故障。这意味着19个验证器比20个更安全,因为在这两种情况下,最多可以容忍6个错误验证器,但是20个中有7个发生故障的可能性比19个中的7个更可能。通常,对于这些一致性算法,数字应为3 f + 1,例如10,13,16或19。

        我们还建议将候选人的数量设置为高于验证人的数量。这样,可能的验证器集的数量非常高,并且攻击者将无法简单地等待特定集发生,其中节点占多数。

  6. 合理

    1. 共识机制

      1. 共识层选项

        POSDAO与许多共识算法兼容。链可以选择最适合其用例和用户的基础算法。例如,AuRa提供一致的块速率,而Honey Badger BFT根据网络性能产生不同的块速率。基于网络的目的,这些变体之一可能是有利的。请注意,AuRa实现将首先完成,HBBFT将在未来版本中实现。

      2. 委托证明(DPOS)

        众所周知,DPOS以限制网络上验证器数量为代价提供高水平的可扩展性。虽然这创造了一种中心化的措施,但研究人员认为“规模为20的拜占庭法定人数制度可以以比资源成本低得多的工作量证明挖矿实现更好的分权。[19] “块生产在预设数量的选定验证器中平均分配,而不是中心化在少数挖矿池中。可以快速有效地处理事务,从而创建高度可扩展的解决方案。

          1. 奖励结构

            1. 最低候选人股份

              最低候选人股份不鼓励候选人席位的潜在中心化,其中个人可能尝试注册许多候选节点,从而控制大部分验证者集合。高最低候选人赌注也会区块一组恶意验证器尝试协调验证器集攻击。该值可根据网络目的和大小进行配置(参见实现参数见9.4)。

            2. 块奖励的平等份额

              验证器集内的每个验证器池都获得块奖励的相等份额。虽然较高的赌注影响候选人池成为验证人池的几率,但每个验证人员池都会获得相同的奖励。这在参与每个铆接时期的验证器之间产生了奇偶性。

            3. 比例奖励分配为70/30%

              70/30分配比率是一种常见的收益分享启发式方法。它是一个可配置的选项,可以在POSDAO部署期间进行更改。当设置为初始值时,委托人在其验证器池中接收块奖励,最高可达总池值的70%,从而激励委托人快速为他们认为应该是验证者的候选池提供资金。

              一旦达到70%的标记,额外的股份将返回相应较小的金额。此时,委托人可以选择为额外的候选人群提供资金,增加潜在候选人的数量和多样性,或者将额外的令牌放入当前的候选人群中,从而增加候选人在下一个赌注时期成为验证人员池的可能性。

              当比率设置为70/30时,验证者从未获得低于池奖励的30%。验证者负责运行节点,奖励基线可以防止委托人可以获得绝大部分奖励的情况。一旦池达到70/30阈值,验证者可以选择增加他们的赌注以吸引额外的委托人

              资金或增加他们在排行榜上的位置。由于声誉是有价值的商品,

              成功的验证器集(具有高赌注,高事务吞吐量和一致的节点正常运行时间)将继续吸引委托人的利益。

            4. 双令牌环境

        POSDAO实现提供了试验不同激励结构的机会。组织可以选择使用单个令牌进行Staking,交易和奖励,或者单独使用令牌进行交易和赌注。在参考实现中,我们使用双令牌环境。

        出于交易目的,我们使用稳定的本机代币(xDai,与主网上的DAI挂钩)。稳定的货币允许用户预测费用并进行价格不会大幅波动的交易。

        出于固定目的,我们使用价格由市场决定的代币。虽然此令牌存在更多波动性,但它不是基于交易的资产。与其他代币一样,价格取决于以太坊生态系统的供需情况。为了提供块奖励,DPOS赌注令牌在侧链上受可配置的年度通货膨胀率限制,但不在主网上。在主网上,令牌供应是固定的。在侧链上,金额按年通货膨胀率增长(在参考实施中,这是所有赌注代币的DPOS_INFLATION_RATE)。此块奖励为验证者和委托人继续赌注提供了额外的激励。

  7. 不良行为和共识故障管理

    在本节中,我们将回顾对共识算法的现有攻击,并提供避免或减轻它们的解决方案。

    虽然POSDAO是一种强大的算法,旨在抵御攻击和不良行为,但在某些情况下协议(以及许多其他协议)容易受到不良行为者联盟的影响。暴露量受基础共识算法的影响。

    网络停顿:串联验证器可能会暂时或无限期地延迟网络消息传递,从而导致网络停滞。如果许多验证器节点并行崩盘或断开,这也可能意外发生。利用修改的AuRa一致性,如果33%或更多的验证器节点受到影响,则网络可能停止(因为修改的AuRa需要至少67%的验证器签名)。使用Honey Badger BFT,33%或更多故障节点可能会导致网络停顿。

    多数共谋:该协议无法抵御大多数串通验证者。在Honey Badger BFT和AuRa中,67%或更多的串通验证器可以改变整个

    协议通过分叉链,密封错误的块,双重花费,或重新选择自己作为验证器。

    1. 远程攻击

      问题

      对手从创世块开始创建替代链(分支)。分支包含不同的事务历史记录,可以在本地维护。使用各种技术,可以在本地分支上加速块生产,以创建比主(诚实)链更长的链。此时,分支机构可以公开,超越作为记录分类账的诚实链条。

      可以通过多种方式创建更长的分支:伪造时间戳,获得对前验证器密钥的访问,或者前验证器之间的串通以快速填充分支(无成本模拟[4]),或者利益泄漏[10],其中恶意验证器减慢由于未能验证块而同时增加备用分支的股份而导致的诚实链。当此攻击成功时,攻击者可以将事务发布到诚实链,等待确认,然后呈现更长的分支以使先前确认的事务无效。

      这个问题最好在基础共识算法的层面上解决。我们建议的两种选择都不受其影响:

      • 一旦验证者签署了一半,AuRa就认为区块是最终的。在我们修改的AuRa实现中,根本不能恢复2 * MAX_VALIDATORS / 3个块。在我们的参考实现中,这意味着除了最后13个块之外的所有块都不会被更改。
      • Honey Badger BFT具有即时终结性,即无法恢复任何区块。
    2. 在Stake攻击中没有任何东西

      问题

      如果链中存在分叉,由于同时产生块或恶意干预,验证者可以选择继续在两个链上生成块,从而在两个链上收集块奖励而不会受到惩罚。实际上,“任何挖矿者(验证者)的最佳策略是在每条链上进行挖矿,这样矿机就可以得到他们的奖励,无论哪个分叉获胜[11]。”这种攻击通过减慢共识时间来降低效率。而且,它

      导致区块链分叉削弱了区块链解决双重花费攻击和其他威胁的能力[12]

      这也取决于潜在的一致性算法防止分叉的能力:

      • Parity的AuRa实现包括一种报告验证器的机制,该验证器提出具有相同编号的多个块。换句话说:在分叉上挖矿导致在主链上的惩罚,所以什么在那种情况下的股份。
      • 使用Honey Badger BFT,除非超过三分之二的验证器串通,否则不可能首先创建一个fork。此外,作者的实现检测并报告行为不当的节点
    3. 假股权攻击

      问题

      在POSv3(基于比特币的)网络中,标头和块作为单独的数据结构发送,并在所有验证检查完成之前提交到存储。这些检查在“工作证明”实施中已足够,但在“证明合并”实施中,会创建多个漏洞[13]。攻击者可以使用伪块头或填充了任意值的假块来泛洪节点。在运行验证检查之前填充RAM(标头)或磁盘空间(块),并使节点不可用。这种攻击的一种变种,称为“花费的攻击[14],“影响使用未花费交易输出(UTX)的POSv3前网络来记录交易。在这种情况下,攻击者可以放大他们的明显赌注,因为验证检查不区分花费和未花费的UTXO。有了这个明显的赌注,攻击者可以在过去的时间挖矿POS块,然后使用这些无效块来压倒节点的磁盘空间。

      在POSDAO中,不直接使用股权来产生一个区块。相反,利益使得它更有可能被选为验证者,并且验证者参与基础共识协议,该协议产生独立于赌注的块。根据该协议,块标头实际上可以非常快速地进行验证:在AuRa中,标题是步骤编号和块的提议者的签名,而在Honey Badger BFT中,它是阈值签名。

    4. 克隆攻击

      问题

      默认的Parity AuRa协议容易受到攻击[15],其中恶意验证器可以克隆其节点(使用相同的公钥/私钥对创建同一验证器的2个或更多个实例),创建网络分区(例如通过延迟)消息[16]),然后在分区的两侧使用这些克隆节点。因为AuRa需要1/2的验证器

      诚实地说,使用克隆的节点会给每个分区上的块验证器带来错觉,这些分区上的组包含一个诚实的多数。

      区块链划分后,攻击者会向每个组发出冲突的事务,从而创建双重支出方案。攻击者等待提交事务,然后在其中一个分区上签署一个额外的块(攻击者想要保留的那个)。这样可以确保具有此附加块的分区成为最长的链(它具有最大的高度),并且其余节点将其接受为规范链。另一个分区以及已经在那里接受的事务将消失。

      将所需的签名数量增加到2/3的验证器而不是AuRa实现中的1/2验证器足以防止此类攻击。只要恶意验证器的数量少于总数的1/3,修改后的算法就可以保证安全性,并且仍然可以保留活跃度(尽管块时间可能会受到轻微影响)

      网络分区的事件)。我们修改了AuRa协议以利用2/3多数来防止克隆攻击。

    5. POSDAO实施特定攻击

      1. RANDAO攻击

        问题

        POSDAO实现需要可靠的随机源来管理验证器集。对于AuRa,我们使用与RANDAO [17]相同的算法,RANDAO [17]是一种广泛使用的去中心化随机数发生器。在“预见”攻击情形中,攻击者通过跳过块生成来利用RANDAO揭示功能。为了可行,这种类型的攻击通常需要共谋或控制多个节点并且愿意放弃块奖励。

        当攻击者跳过块验证时,他们可以使用显示的信息来预先计算“(可能很多)”揭示策略的可能结果……从而可以预测他们对过程的贡献的影响并将生成的随机数偏向他们的优点。[18] “

        POSDAO合约知道验证人是否透露了他们的秘密。如果验证器每个Staking时间没有显示超过20次(此值是根据STAKE_WITHDRAW_DISALLOW_PERIOD和COLLECTION_ROUND_LENGTH常量计算的),

        它们在该时期的最后一个块被视为恶意,并被算法从活动池列表中删除。在这种情况下,验证者及其所有委托人在接下来的90天内被标记为禁止(BAN_PERIOD),他们无法从

        在此期间禁止股权池。被禁止的股权池不能参加以下赌注时期90天。

        这个限制为20允许每个赌注时期跳过是为了避免惩罚临时停机的验证器。但是,它还允许恶意验证者通过伪造此类中断来影响结果。这种权衡避免了有时禁止诚实验证器的连接问题,代价是使随机数不太安全。当数字用于高价值应用程序(例如高赌注的赌场游戏)时,限制应该可能为0,并且应该期望验证器运行多个节点或采取其他措施来防止任何中断。

        如果验证者决定不在最后一轮曝光期间揭露他们的秘密(影响结果),他们将被视为恶意。验证者有责任确保他们的节点在Staking时期的最后一个块期间正常运行并连接。即使他们在这个阶段只是失去了联系,他们也会被删除。

        我们建议验证器同时使用不同的Internet连接运行两个单独的节点以确保可靠性:具有engine_signer选项的主节点和没有该选项但具有保护脚本的辅助节点,当第一个节点脱机时,该脚本动态地为辅助节点设置该选项。由于不建议在云中运行节点(出于安全原因),每个验证器应在多个安全数据中心中拥有节点。

        在赌注时期的最后6个小时(STAKE_WITHDRAW_DISALLOW_PERIOD)期间(此持续时间是可配置的),没有人可以放弃或移除,从而防止对结果产生任何可能的影响。

        唯一可能的攻击是如果验证者选择在Staking时期结束时不揭示秘密。这导致验证者的赌注(以及委托他们的所有委托人)被冻结,并且禁止参与90天(BAN_PERIOD)。

      2. 移除桥攻击

        问题

        为了实现与以太坊的互操作性,多个桥接实例可以将POSDAO链连接到以太坊主网(有关详细信息,请参见5.1)。桥上的验证器负责在桥的一侧锁定资产并在另一侧锁定资产。在执行这些操作之前,这些操作需要来自多个验证器的多个签名。桥接验证器与POSDAO链上的验证器不同,并且每个桥接实例都需要一组预定的验证器(它们对于每个桥接器可以是相同的或单独的)。

        大多数桥接验证器(恶意或受损节点)可能会占用桥梁合约和薄荷资产而没有相应的锁定资产。这将创建没有真实资产支持的代币或代币。绝大多数人还可以解锁桥梁另一侧的资产并排出锁定的资金。

        与POSDAO共识验证器分开,桥接验证器是知名人士,他们为保护桥梁合约而信誉良好。这些人(通常是组织)是社区参与者,他们同意承担管理桥梁的职责。尽管可以通过治理流程添加或删除验证器,但桥验证集不会定期轮换。此外,还有每日限制可以防止未经检查的资产创建,销毁或转移。如果超出限制,则任何请求中继资产的事务都将失败。

      3. 协调验证器设置攻击

        问题

        一组串联的恶意验证器(超过集合的67%)可能通过部署新的POSDAO合约,更改其节点上的spec.json,然后重新启动其节点来破坏网络。新spec.json文件将包含在新的块数engine.authorityRound.params.validators.multi(见https://github.com/poanetwork/poa-chain-spec/blob/core/spec.json)。这将创建一个硬分叉,验证器将控制合约的代码。

        正如第6节的介绍中所提到的,协议本身无法抵御大多数串通验证器。但是,增加CANDIDATE_MIN_STAKE参数会大大降低此攻击的可行性,这使得密谋组的尝试成本极高。通过增加此常量的值,组的汇总成本大大增加,阻碍了协调恶意超越的任何努力。

  8. 未来发展方向

    1. Honey Badger BFT全面实施

      虽然POSDAO算法可配置为允许不同的共识机制,但AuRa共识是目前协议完全支持的唯一方法。我们正在努力将HoneyBadger BFT整合为替代的可插拔共识。参见附录E了解更多详细信息

    2. 桥梁治理发展

      在桥接方案中,桥接验证器被授予多重所有者状态。它们在发布期间受到信任,并且在参考实现中是可靠的组织。我们将探索桥梁治理战略,以促进未来版本的进一步去中心化。

    3. 奖励模型分析

      高度可配置的激励结构允许我们对不同的奖励方案进行建模(参见附录D)。我们将继续测试其他设计,以微调和探索不同奖励模型的影响。

    4. 质押

      可以通过加密货币借贷服务(例如Compound)将债券中的“锁定”分配为贷款的抵押品。必须有保证,以便在发起桥梁转移时,根据要求返回任何锁定的资金。我们将探索这种方法以确保其合理,并分析这种新方法的成本/收益,以提供额外的赌注激励。

  9. 参考实施说明

    1. POSDAO智能合约

      POSDAO使用一 Solidity 智能合约进行配置以实现共识,奖励和赌注逻辑。

      • BlockRewardAuRa 根据第3节中描述的逻辑和公式生成和分配奖励。主要功能包括:
        • 从验证者及其代理人之间的ERC20到ERC20,Native-to-ERC20和/或ERC20到Native网桥分配入口/出口费用;
        • 在验证人及其代理人之间分配1%/年通货膨胀的赌注代币;
        • 为ERC20-to-Native桥梁所需的薄荷糖原生代币;
        • 在每个堆积时期开始时生成验证器及其委托者的快照,并在Staking时期使用该快照向验证者及其委托人增持奖励。
      • 验证者:允许验证人员为其服务交易使用零汽油价格(有关详细信息,请参阅Parity Wiki)。以下功能被视为服务事务:
        • ValidatorSet.emitInitiateChange

        • ValidatorSet.reportMalicious

        • RandomAura.commitHash

        • RandomAura.revealSecret

      • InitializerAuRa 在网络启动时使用一次,然后在创世块上销毁。初始化创世块上的可升级合约需要此合约。此契约的字节码由scripts / make_spec.js脚本与其他契约一起写入spec.json
      • KeyGenHistory 存储Honey Badger BFT引擎所需的验证器公钥以及存储HBBFT节点使用的事件。

      • RandomAuRa RANDAO方式生成和存储随机数(并控制AuRa验证器何时显示它们)。随机数用于通过ValidatorSet契约在每个堆积时期开始时形成新的验证器集。主要功能包括:
        • commitHashrevealSecret。这些只能在生成并显示其加密货币时由验证者的节点调用(请参阅RANDAO以了解其原理)。每个验证器节点必须在每次“集合轮次”中调用这些函数一次。这将创建一个随机种子,由ValidatorSetAuRa合约使用;
        • onFinishCollectRound 。该功能由。自动调用

          每个“集合轮次”结束时的BlockRewardAuRa合约。它控制验证器节点的显示阶段,并在它们不显示时惩罚验证器(有关禁止协议的更多详细信息,请参见7.5.1)。

      • 注册表存储与地址相关的人类可读密钥,如DNS信息(请参阅Parity Wiki)。该合约主要用于存储TxPermission 合约的地址有关详细信息请参阅Parity Wiki)。
      • StakingAuRa 包含Staking逻辑,包括:

        • 候选人和验证人创建,存储和删除池;
        • 参与者(代理人,候选人或验证人)将标记放入池中;
        • 存储参与者的赌注;
        • 来自池的参与者撤回代币;
        • 参与者在股权池之间移动令牌;
        • 如果参与者要求,在赌注时期结束时执行自动令牌提取。
          • TxPermission 控制服务交易中验证者使用零汽油价格,保护网络免受恶意验证者的“交易垃圾邮件”。保护逻辑在allowedTxTypes函数中声明。
          • ValidatorSetAuRa 存储当前验证器集,并包含在每个Staking时期开始时选择新验证器的逻辑。该逻辑使用由RandomAuRa合约生成和存储的随机种子。此外,ValidatorSetAuRa修改后的Parity客户端负责发现和删除恶意验证器。此合约基于Parity Wiki中描述的ReportingValidatorSet

          请注意,HBBFT合约实现尚未完全完成,并且未在此处上架或描述它们。

          有关合约的每个功能的详细说明,请参阅源代码

    2. 实施细节

      以下是xDai DPOS AuRa实现的详细概述。请注意,随着进一步优化,这些细节可能会发生变化。任何协议更改都将记录在更新版本中。

      1. 网络启动

        在网络启动之前,我们编译所有共识契约,并使用make_spec.js脚本在spec.json 文件中编写其字节码。已编译的字节码包含具有构造函数的那些合约的构造函数参数。

        网络应该有几个初始验证器,它们在InitializerAuRa合约的构造函数中定义。我们将其地址传递给make_spec.js示例)以及其他必要参数,以在genesis块上配置网络。

        spec.json文件准备好之后,初始验证器必须配置并启动它们的Parity节点。每个节点都使用spec.json 作为链规范

        契约的字节码被写入创世块的链中。

        网络启动后,系统会在块#1开始时调用ValidatorSetAuRa.finalizeChange函数(有关详细信息,请参阅Parity Wiki)。此函数将initiateChangeAllowed布尔标志设置为true(此标志由ValidatorSetAuRa.emitInitiateChange函数使用,该函数由验证程序的节点调用

        当有一个非空的待定验证器列表时)。该

        ValidatorSetAuRa.finalizeChange 函数在下面更详细地描述。

        从创世块开始,初始验证器没有赌注,因为尚未部署ERC合约。在部署ERC合约并安装ERC20-to-ERC20和ERC20-to-Native网桥后,他们可以放置股份。

        除了初始验证器,我们还定义了合约的所有者。该老板是用于桥梁部署和未来的合约可升级的地址。最初,所有者可以进行零天然气价格服务交易,因为其余额中没有本地代币。

        所有者部署ERC合约和桥(ERC20-to-ERC20和ERC20-to-Native)时,将调用以下函数:

        • BlockRewardAuRa.setErcToErcBridgesAllowed

        • BlockRewardAuRa.setErcToNativeBridgesAllowed

        • StakingAuRa.setErc20TokenContract

        • ERC677BridgeTokenRewardable.setBlockRewardContract

        • ERC677BridgeTokenRewardable.setStakingContract

        那么老板:

        1. 使用其构造函数中定义的可信地址部署MultiSigWallet协定。
        2. 为其部署的每个合约和每个共识合约调用 transferOwnership功能(可能有另一个名称,具体取决于合约)。
        3. 将其地址传递给Certifier.revokeTxPermission.removeAllowedSender函数,以禁止自己使用零汽油价格服务交易。此时,所有者成为没有特殊系统权限的常规地址。

        当每个块关闭时,BlockRewardAuRa.reward函数由创建该块的验证器节点调用。这是一个奇偶校验功能,它发生在每个块中(没有间隙

        – 请参阅https://wiki.parity.io/Block-Reward-Contract.html)。此函数主要用于动态块奖励,但我们将其用于DPOS,因为BlockRewardAuRa.reward没有

        区块气体限制,允许我们进行大量计算。更详细地描述了该功能

        下面。

      2. 放置赌注

        在第一个赌注时期,初始验证器将赌注放入他们自己的池中,以便在第一个赌注时期结束后保留​​他们的座位。

        每个验证器都有两个地址:一个挖矿地址和一个Staking地址。该矿山地址

        使用由验证器的节点(该地址必须被指定为engine_signer解锁

        theParity节点配置toml文件)进行零天然气价格服务交易。该铆接地址被用于其它目的(放置树桩,存储令牌,等)

        要通过其Staking地址检索挖矿地址,反之亦然,可以使用ValidatorSetAuRa.miningByStakingAddressstakingByMiningAddress getter。

        赌注令牌从以太坊主网(外国网络)获得并桥接到xDai DPOS链。

        1. DPOS ERC20标记令牌

          DPOS令牌作为ERC20令牌存在于以太坊主网上。这些令牌的供应量有限,获得它们的确切供应和方法是TBD。获得后,用户可以使用ERC20-to-ERC20桥将其令牌传输到xDai DPOS链。与此转移相关的入场费和DPOS ERC20令牌将转换为DPOS ERC677令牌。然后将这些代币放置为桩,如下所述。根据仅在xDai DPOS链上发生的年度通货膨胀率,以套利代币支付套利奖励。这意味着当主网上的DPOS不可用时,DPOS ERC677的总供应量可能与主网上DPOS ERC20的总供应量不同。

        2. 初始验证者赌注

          要放置赌注,验证器必须至少在其Staking地址的ERC余额上具有CANDIDATE_MIN_STAKE(参见StakingAuRa.getCandidateMinStake getter)令牌该地址还必须有本地代币的余额来支付天然气费用。要从以太坊主网(外部网络)获取标记令牌令牌,验证器使用

          ERC20-to-ERC20桥。为了获得本机代币,验证器使用ERC20-to-Native网桥将ERC20 DAI令牌从外部网络传输到家庭网络。

          令牌和本地代币使用的桥梁外网接收后,初步验证调用StakingAuRa.stake从功能上跑马圈地的地址

          非零天然气价格。验证者传递其赌注地址和赌注金额(更高

          等于或等于CANDIDATE_MIN_STAKE)作为参数。

        3. 候选人赌注

          新候选人必须:

          1. 从外国网络获取令牌和本地代币。
          2. 启动他们的Parity节点。
          3. 从他们的赌注地址调用StakingAuRa.addPool并将赌注金额(> = CANDIDATE_MIN_STAKE)及其挖矿地址作为参数传递。该StakingAuRa.addPool功能类似于StakingAuRa.staking,但只适用于考生。
        4. 代表团赌注

          委托人必须:

          1. 从外国网络获取令牌和本地代币。
          2. 调用StakingAuRa.stake函数并传递他们想要放置其赌注的验证者/候选人的赌注地址,以及大于或等于DELEGATOR_MIN_STAKE的赌注金额(参见StakingAuRa.getDelegatorMinStake getter)。
        5. Staking窗口

          StakingAuRa.stakeStakingAuRa.addPool如果功能只能被称为StakingAuRa.areStakeAndWithdrawAllowed吸气返回。该吸气剂定义了铆接时期内的窗口,在此期间参与者可以进行铆接和取出。对于AuRa,此窗口在引擎应用新的验证器集之后立即开始(调用ValidatorSetAuRa.finalizeChange),并在禁止期开始时在Staking时期的最后一个块结束(禁止期持续时间由StakingAuRa.stakeWithdrawDisallowPeriod定义))。

        6. 有用的StakingAuRa吸气剂
  • StakingAuRa.stakeAmount 指定地址对指定池的总赌注金额。

  • StakingAuRa.stakeAmountTotal 由所有委托者和指定的Staking地址生成的指定池的总赌注金额。

  • StakingAuRa.getPools 活动池列表(候选和验证器的Staking地址列表)。

  • StakingAuRa.poolDelegators 指定池的当前委托者列表。

      1. 新的staking时期,验证器选择和最终更改

        在每个赌注时期,参与者可以调用这些功能:

        • StakingAuRa.stake:放置赌注;

          • StakingAuRa.addPool:创建一个新池;

          • StakingAuRa.withdraw&StakingAuRa.orderWithdraw:撤回赌注;

          • StakingAuRa.moveStake:移动赌注。

          staking epoch的最后一个块上,BlockRewardAuRa.reward函数调用

          ValidatorSetAuRa.newValidatorSet 函数。这个功能:

          • 分析当前池(候选人和验证人)的赌注金额;
          • 选择新的验证器;
          • 将新验证器列表(验证器集)写入挂起列表 ;
          • 挂起的列表写入队列,然后由队列读取

            ValidatorSetAuRa.emitInitiateChange 函数;

          • 递增由返回的赌注时期编号

            StakingAuRa.stakingEpoch getter;

          • 重置由…返回的验证器集应用块的编号

            ValidatorSetAuRa.validatorSetApplyBlock getter。

            如果候选者和验证者的总数小于或等于MAX_VALIDATORS,它们将在下一个赌注时期成为验证者。否则,基于随机值选择验证器并按其池大小加权(池越大,候选者成为验证器的可能性越大)。随机种子取自RandomAuRa合约,如下所述。

            可以通过以下方式读取待验证的新验证器列表(它们的挖矿地址)

            ValidatorSetAuRa.getPendingValidators getter。

            验证程序集不能立即更改,因为必须在此更改之前发出InitiateChange事件(请参阅Parity Wiki),因此挂起的验证程序集将排队等待稍后由ValidatorSetAuRa.emitInitiateChangeValidatorSetAuRa.finalizeChange函数处理。

            ValidatorSetAuRa.finalizeChange功能只要求一个InitiateChange事件。如果有多个此类事件,则对第一个发出的事件仅调用一次finalizeChange(并忽略其他InitiateChange事件)。因此,除非前一个事件未完成,否则我们无法发出下一个InitiateChange

            出于这个原因,存在的由所使用的验证集的队列ValidatorSetAuRa.emitInitiateChange功能。当ValidatorSetAuRa.emitInitiateChangeCallable吸气返回,一个验证器的节点调用ValidatorSetAuRa.emitInitiateChange其离队未决验证组,并发射InitiateChange事件让验证节点都知道这组验证应当改变(见奇偶维基)。

            InitiateChange发射事件时,ValidatorSetAuRa.emitInitiateChange功能设置initiateChangeAllowed布尔标志,以虚假,使ValidatorSetAuRa.emitInitiateChangeCallable吸气返回,直到ValidatorSetAuRa.finalizeChange由引擎调用。

            应用新的验证器集后,引擎调用ValidatorSetAuRa.finalizeChange函数,让ValidatorSetAuRa合约知道必须将排队的挂起验证器集写入ValidatorSetAuRa.getValidatorsgetter 返回的当前验证器集。

            此时,ValidatorSetAuRa.finalizeChange函数:

          • 用排队的验证器集替换当前的验证器集;
          • 保存在上一个赌注时期制作的赌注金额的快照;
          • validatorSetApplyBlock设置为当前块编号;
          • initiateChangeAllowed布尔标志设置为true

          所述ValidatorSetAuRa.validatorSetApplyBlock吸气剂被用来确定其中当前验证组是由发动机施加的块号。如果此getter返回0,则表示启动了新的staking epoch(调用了ValidatorSetAuRa.newValidatorSet),但引擎尚未应用新的验证器集。在此期间不允许使用赌注和取款(参见StakingAuRa.areStakeAndWithdrawAllowed getter)。

      2. 验证器设置更改和验证器集队列

        验证器集始终在Staking时期结束时进行评估,但是,如果由于行为不当需要删除验证器,也可以在Staking时期更改验证器集。

        在这种情况下,恶意验证器将从验证器中心化删除(请参阅内部ValidatorSetAuRa._removeMaliciousValidatorAuRa函数),新的待处理验证器集将排队等待稍后由ValidatorSetAuRa.emitInitiateChangeValidatorSetAuRa.finalizeChange函数处理。

        与staking epoch验证器集更改一样,ValidatorSetAuRa.finalizeChange

        函数用于在删除恶意验证器时完成验证器集更改。

        验证器集队列用于一个接一个地完成不同的验证器集。当移除恶意验证器并且在移除后立即开始新的堆积时期,或者在块编号N处移除一个恶意验证器,但是在下一个块N + 1上移除另一个恶意验证器时,可能需要这样做。如果没有队列,则会错误地处理这种情况,因为引擎会忽略一些相应的InitiateChange事件(如上所述)。

      3. 随机种子增持

        当池(验证器+候选者)的数量超过MAX_VALIDATORS时,随机种子用于为新的Staking时期选择MAX_VALIDATORS验证器(请参阅ValidatorSetBase._newValidatorSet内部函数)。

        随机种子存储在RandomAuRa合约中(参见RandomBase.getCurrentSeed getter)并以RANDAO方式生成:每个堆积时期有几个收集轮,每个收集轮分为两个相等的阶段 – 提交阶段和显示阶段:

        1. 提交阶段:每个验证器节点在每个阶段生成其加密货币,并调用RandomAuRa.commitHash函数以提交秘密的散列(每个提交阶段一次)。
        2. 揭示阶段:每个节点将其秘密传递给RandomAuRa.revealSecret函数(每个节点显示一次)。该RandomAuRa.revealSecret功能XOR运算存储在合约的当前种子的秘密透露。每轮收集都会增加熵。

        每个验证者都必须承诺/泄露秘密。每个验证器的节点从验证器的挖矿地址自动调用这些函数(见9.3)。

        收集轮的长度是在InitializerAuRa中的网络启动时定义的

        合约构造函数。

        RandomAuRa.onFinishCollectRound函数被调用由每块上BlockRewardAuRa.reward功能。在每个集合轮结束时,RandomAuRa.onFinishCollectRound检查验证器是否在收集轮次中跳过显示秘密,如果他们这样做则增加跳过计数器。

        在每个赌注时代的最后一轮收集

        RandomAuRa.onFinishCollectRound 函数检查每个验证器以查看

        1. 如果他们在目前的赌注时代过于频繁地暴露,或者,
        2. 如果他们在最后一轮收中心化跳过揭示。

        如果其中任何一个都为真,那么验证程序将被视为恶意程序并将其删除

        ValidatorSetAuRa.removeMaliciousValidator 函数。

        显示跳过的最大数量在RandomAuRa.onFinishCollectRound函数中定义,并取决于不允许的持续时间(参见StakingAuRa.stakeWithdrawDisallowPeriod getter)和收集轮的长度(请参阅RandomAuRa.collectRoundLength getter)。

        最后一轮收集对于检查尤为重要。在最后一轮中,验证器中心化的最后一个验证器可以决定不泄露其秘密以试图影响ValidatorSetBase._newValidatorSet函数中的结果。出于这个原因,任何在上一轮收集过程中未泄露其秘密的验证器都被视为恶意验证并从验证器中心化删除。

        为防止由于断开连接而意外发生这种情况,建议每个验证器使用不同的Internet连接同时运行两个单独的节点。第一个节点必须在配置toml文件中具有engine_signer选项,第二个节点不应具有该选项,但应具有watchguard脚本,该脚本检测第一个节点是否脱机并为第二个节点设置engine_signer 选项(请参阅https:/ /github.com/poanetwork/posdao-test-setup/issues/39)。

        由于引擎可以在任何时间应用新的验证器集(例如,在某些提交/显示阶段的中间),因此可能存在新验证器无法在最开始时完全提交/揭示其秘密的情况。赌注时代。因此,在应用新验证器集之后存在短暂的宽限期,在此期间,如果跳过显示,则跳过计数器不会递增(请参阅RandomAuRa.onFinishCollectRound函数的代码)。

        RandomAuRa.commitHashRandomAuRa.revealSecret以零汽油价格调用。这是启用的,因为验证器的挖矿地址可以具有零余额。

        被恶意验证器调用,以防可能的垃圾邮件网络RandomAuRa零天然气价格过于频繁的功能,有在执行的保护机制TxPermission.allowedTxTypes功能:它不允许创建RandomAuRa交易,除非他们被允许在当前块(请参阅RandomAuRa.commitHashCallableRandomAuRa.revealSecretCallable getters)。

        TxPermission.allowedTxTypes吸气剂是由被称为奇偶校验节点每一次新的交易即将被添加到块。此getter检查事务是否可以包含在块中。

      4. 删除恶意验证程序

        有两种情况可以通过错误行为删除验证器:

        1. 由于没有泄露秘密数字而被RandomAuRa合约(见上文);
        2. 通过ValidatorSetAuRa.reportMalicious函数(参见Parity Wiki)。

        ValidatorSetAuRa.reportMalicious功能可以通过验证被要求在指定块号报告指定的验证器的不当行为。如果超过50%的验证器报告同一块的相同验证器,则验证器将从验证器中心化删除(请参阅ValidatorSetAuRa.reportMalicious函数的代码)。

        验证器的节点以零汽油价格调用ValidatorSetAuRa.reportMalicious。这是启用的,因为验证器的挖矿地址可以具有零余额。

        为了保护网络免受恶意验证器通过调用具有零气价的ValidatorSetAuRa.reportMalicious函数的可能的垃圾邮件,在TxPermission.allowedTxTypes函数中实现了一种保护机制:它不允许创建ValidatorSetAuRa.reportMalicious事务除非在当前块上允许(请参阅ValidatorSetAuRa.reportMaliciousCallable getter)。

        此外,如果某些验证经常调用ValidatorSetAuRa.reportMalicious(比其他验证器更频繁),则此类验证器也被视为恶意验证(请参阅ValidatorSetAuRa.reportMaliciousCallableValidatorSetAuRa.reportMalicious)。

        验证器删除过程在ValidatorSetBase._removeMaliciousValidator内部函数中实现。它由ValidatorSetAuRa._removeMaliciousValidatorAuRa调用。删除验证程序后,将禁止其BAN_PERIOD 的挖矿地址。这意味着被禁止的验证器及其委托人在BAN_PERIOD到期之前无法撤回其赌注(请参阅StakingBase._isWithdrawAllowed内部函数)。此外,在此期间,禁止的挖矿地址无法添加到验证器中心化。

        当从当前验证器中心化删除验证器时,新的待处理验证器集将排队并等待传递给InitiateChange事件(见9.2.4)。

        有用的公共吸气者:

        • ValidatorSetAuRa.isValidatorBanned:检查是否禁止指定的挖矿地址;

          • ValidatorSetAuRa.banCounter:读取禁止计数器,禁止验证器时递增计数器;

          • ValidatorSetAuRa.bannedUntil:从禁令中释放挖矿地址时查看块编号。

          在测试网络中,可以设置一个不可移除的验证器(见9.2.11)。即使由于行为不当,也无法从验证器中心化删除此类验证器(请参阅下面的ValidatorSetBase._removeMaliciousValidator和有关不可移除验证的部分)。如果验证器集存在问题(例如,如果所有验证器同时离开网络),此功能可防止测试网络关闭。

      5. 区块奖励分配

        块奖励通过BlockRewardAuRa.reward函数在验证器及其委托者之间分配。关闭每个块时,引擎会调用此函数。

        池奖励分配逻辑在BlockRewardBase._distributePoolReward内部函数中实现。池奖励是根据在Staking时期开始时自动创建的公式和赌注金额计算的(请参阅ValidatorSetAuRa.finalizeChange调用的BlockRewardAuRa.setSnapshot)。在赌注时期期间股权金额的变化不会影响该时期的集合奖励,但它们确实会影响在下一个赌注时期收集的未来奖励。

        有多种块奖励可用于分发:

        • ERC20-to-Native桥费;
        • ERC20-to-ERC20或Native-to-ERC20桥费;
        • 通胀分配。
        1. ERC20-to-Native桥费分配

          在桥接器将费用金额传递给BlockRewardAuRa.addBridgeNativeFeeReceivers函数之后,在下一个块上发生此分布。费用以原生代币(xDai)分配。

          当桥传递费用金额时,其值存储在合约中,并由BlockRewardAuRa._distributeBridgeFee内部函数在下一个块上读取。费用金额将传递到BlockRewardAuRa._distributeAmount,其中包含奖励分配逻辑。该函数返回地址列表和相应的金额。然后,BlockRewardAuRa.reward函数将列表返回给引擎,该引擎为指定地址分配指定数量的本机代币。

        2. ERC20-to-ERC20或Native-to-ERC20桥费分配

          在桥接器将费用金额传递给BlockRewardAuRa.addBridgeTokenFeeReceivers函数之后,此分布发生在下一个块上。费用在ERC赌注令牌(DPOS)中分配。

          当桥传递费用金额时,其值存储在合约中,并由BlockRewardAuRa._distributeBridgeFee内部函数在下一个块上读取。费用金额将传递到BlockRewardAuRa._distributeAmount,其中包含奖励分配逻辑。该函数返回地址列表和相应的金额,并将列表传递给ERC合约的mintReward函数。

        3. 通货膨胀分配

第二个铆接时期开始,每个块发生这种分布。它需要知道所有活动验证器池中的赌注总量,因此它必须等到放置这些赌注并在Staking时期开始时拍摄快照。

BlockRewardAuRa._distributeInflation内部函数被调用每一个块。它通过ValidatorSetAuRa.finalizeChange函数读取在Staking时期开始时计算和创建的总赌注金额,其中应用了新的验证器集(请参阅BlockRewardAuRa.setSnapshot)。给定金额乘以常数,使通货膨胀率为每年DPOS_INFLATION_RATE百分比。计算完成后,数量由验证者及其委托人中的BlockRewardAuRa._distributeAmount分配。

      1. 撤回赌注

        任何参与者都可以使用StakingAuRa.withdraw函数撤回其股份(或其中的一部分)。用户传递池的Staking地址和从该池中移除的金额。

        在允许赌注的同一时期内允许取款(见9.2.2)。

        用户可以撤回其全部赌注或部分赌注。在后一种情况下,用户必须在池中至少留下DELEGATOR_MIN_STAKE或CANDIDATE_MIN_STAKE(取决于他们的角色)。

        如果用户移除尚未成为验证者的候选人池,他们可以撤回其全部股权金额。

        当从验证器的池中移除时,用户只能提取他们在当前铆接期间Staking的金额(参见StakingAuRa.maxWithdrawAllowed getter),或者他们可以订购提款。该金额将在赌注时期结束时自动撤销(参见StakingAuRa.performOrderedWithdrawals,它在新的赌注时代开始时由BlockRewardAuRa.reward调用)。

        StakingAuRa.maxWithdrawAllowed吸气检查最大电流允许开采量。如果池是活动验证器,则基于现有提取订单以及当前Staking时期期间Staking的金额来计算最大可能提取量。

        StakingAuRa.maxWithdrawOrderAllowed吸气检查最大可能的提款金额可以订购。如果池是活动验证器,则根据现有提款订单计算最大可能提取金额。

        StakingAuRa.orderWithdraw功能下令撤军。池的Staking地址和要提取的金额将传递到函数中。通过将负值传递给StakingAuRa.orderWithdraw函数,也可以减少或取消订购的提款金额。

        StakingAuRa.orderedWithdrawAmount公共吸气剂检查当前有序取款金额。

        在当前铆接时期期间订购的提取是在StakingAuRa.performOrderedWithdrawals函数的下一个铆接时期开始时自动执行的。BlockRewardAuRa.reward自动调用此函数。撤销订购金额在StakingBase._performOrderedWithdrawals中实施

        内部函数执行多次检查,然后调用ERC令牌合约的撤销功能。

      2. 移动赌注

        除了撤回赌注之外,参与者还可以使用StakingAuRa.moveStake功能将他们的赌注(或他们的一部分赌注)从一个池移动到另一个池。这可以防止在从一个池移动到另一个池时从StakingAuRa合约的平衡中移除铆接令牌。股权移动功能受制于上述提款功能的相同规则和限制。

      3. 自愿移除验证器组

        如果验证器想要从验证器集移除,则可以使用以下方法之一:

        1. 验证器可以从其Staking地址调用StakingAuRa.removePool函数。验证器的池通过此函数从活动池列表中删除,因此该池不会参与在下一个Staking时期开始时形成新的验证器集(请参阅ValidatorSetBase._newValidatorSet内部函数)。
        2. 验证者可以使用StakingAuRa.orderWithdraw函数命令提取其全部股权金额(见9.2.8)。在这种情况下,验证器将在下一个Staking时期开始时在它们自己的池中具有零余额,并且ValidatorSetBase._newValidatorSet内部函数将不会选择该池。
      4. 不可移除的验证器

        可选地,POSDAO网络可以具有一个不可移除的验证器(仅推荐用于测试网络)。这是在网络启动时通过InitializerAuRa契约定义的一次(请参阅构造函数的_firstValidatorIsUnremovableboolean参数)。如果参数为true,则构造函数中定义的第一个初始验证程序是不可移除的。

        这样的验证器不能通过ValidatorSetBase._newValidatorSet从验证器中心化移除(即使验证器没有为自己放置任何赌注),也不能通过ValidatorSetAuRa.reportMalicious函数。但是,如果他们想要更改其不可移除状态,则可以调用ValidatorSetAuRa.clearUnremovableValidator函数。合约的所有者也可以调用此功能。该ValidatorSetAuRa.clearUnremovableValidator函数只能被调用一次。在调用之后,不可能有另一个不可移除的验证器。

        ValidatorSetAuRa.unremovableValidator公共的getter检索跑马圈地地址不可移除的验证器。如果此getter返回零地址,则验证器中心化没有不可移除的验证器。

      5. 零天然气价格和服务交易

店主和当前的验证程序是能够从他们做服务交易(零个天然气价格经常交易)挖矿地址。这是通过验证者完成的

合约; 它的地址写入注册表合约(参见Parity Wiki)。该业主

已在上面的9.2.1中提到过。

最初,验证器在执行事务时没有任何本地代币支付燃气费(当调用RandomAuRa.commitHashRandomAuRa.revealSecretValidatorSetAuRa.emitInitiateChangeValidatorSetAuRa.reportMalicious函数时;参见9.3)。因此,他们的挖矿地址可以调用零天然气价格的功能。

所有交易均由TxPermission合约控制:除非在当前块上允许,否则不允许创建零天然气价格交易(请参阅TxPermission.allowedTxTypes函数)。这可以防止滥用零气价:上述服务功能只有在允许的情况下才能调用,因此不能过于频繁地调用它们来对网络进行垃圾邮件。

    1. 修改了AuRa的奇偶校验客户端

      为了使用AuRa启动POSDAO网络,已修改稳定的Parity版本以与POSDAO合约一起使用。我们的修改版本包含以下差异:

      • 验证器节点通过调用随机性契约自动参与随机数生成。在提交阶段,它们生成一个随机数并在合约上发布其哈希值。在揭示阶段,他们自己发布数字。最终的随机数是从所有验证者的贡献中生成的。
      • 验证者如果观察到其他不遵循协议的验证者,则调用reportMalicious函数(请参阅Parity Wiki)。
      • 验证器节点创建一个块,验证器集在其中发生更改,因为新的Staking时期开始或者因为即将删除恶意验证器,会自动发出InitiateChange事件(请参阅Parity Wiki)。
      • 事务许可合约及其接口已扩展,并允许验证者以零天然气价格对我们的治理合约进行大多数调用,因此签署地址不需要非零余额。这包括所有上述调用。扩展接口现在不仅可以通过发件人,合约地址和价值进行过滤,还可以通过天然气价格和交易数据进行过滤。
      • 我们还实现了验证器直接推送他们的机制与治理相关的事务,它们正在准备的块上,因此它们不必首先通过事务队列。某些交易(如恶意报告)同时使用这两种交易因此,即使节点已经在Staking时期结束时从验证器中心化移除,它仍然可以将其报告发送给其他人。
      • 我们将签名要求增加到valid验证器而不是½以防止克隆攻击情形。
    2. xDai DPOS网络参数

      xDai DPOS参考实现中使用的常量

      不变

      单元

      MAX_CANDIDATES

      2000

      候选人(包括验证人)

      MAX_VALIDATORS

      22

      验证

      CANDIDATE_MIN_STAKE

      1

      STAKE_UNITs

      DELEGATOR_MIN_STAKE

      1

      STAKE_UNITs

      STAKE_UNIT

      10 ** 18

      本机代币或ERC20令牌,小数点后18位

      SYSTEM_ADDRESS

      2 ** 160 – 2

      BAN_PERIOD

      90

      STAKING_EPOCH_PERIOD

      7

      COLLECTION_ROUND_LENGTH

      200

      STAKE_WITHDRAW_DISALLOW_PERIOD

      6

      小时

      DPOS_INFLATION_RATE

      1

      年度%

      BRIDGE_ENTRANCE_FEE

      1

      BRIDGE_EXIT_FEE

      1

      附录A:DPOS奖励分配

      此处提供了可手动配置值的工作版本。总金额:每块1025英镑的奖励:10,101.25

      库1

      赌注金额

      奖励

      奖励代币

      图片

      验证器

      2000

      三十

      10

      委托者

      1000

      14

      4.666666667

      委托者

      1000

      14

      4.666666667

      委托者

      1000

      14

      4.666666667

      委托者

      1000

      14

      4.666666667

      委托者

      1000

      14

      4.666666667

      总:

      7000

      33.33333333

      委托者:

      5000

      池2

      赌注金额

      奖励

      奖励代币

      图片

      验证器

      10000

      三十

      10

      委托者

      100

      0.2491103203

      0.08303677343

      委托者

      1000

      2.491103203

      0.8303677343

      委托者

      10000

      24.91103203

      8.303677343

      委托者

      10000

      24.91103203

      8.303677343

      委托者

      1000

      2.491103203

      0.8303677343

      委托者

      6000

      14.94661922

      4.982206406

      总:

      38100

      33.33333333

      委托者:

      28100

      Pool3

      赌注金额

      奖励, %

      奖励,代币

      图片

      验证器

      5000

      49.5049505

      16.50165017

      委托者

      100

      0.990099009

      9

      0.3300330033

      委托者

      5000

      49.5049505

      16.50165017

      委托者

      0

      0

      0

      委托者

      0

      0

      0

      委托者

      0

      0

      0

      总:

      10100

      33.33333333

      委托者:

      5100

      附录B:DAI-to-xDai / ERC20-to-Native网桥示例场景

      假设:

      • 验证者/委托人当选并已建立桥接DPOS令牌
      • 转换率为1 DAI = 1 xDai
      • 大桥入场费为1%,移除费为1%
      • 相同的共识验证者积极进入和移除。如果不同的赌注时期,不同的验证员和委托人可能会收到入场/出境费

        验证器池赌注:

      • 验证器池1:验证器1有100个DPOS,2个委托者每个有100个DPOS(总共300个)
      • 验证器池2:验证器2有100个DPOS,1个委托者有300个(总共400个)
      • 验证器池3-10是单实体验证器,每个验证器具有200个DPOS

        用户希望将xDai DPOS链用于可伸缩性目的。他们将100 DAI转​​移到xDai DPOS链中。

        1. 100 DAI被发送到主网桥合约。
        2. 100 DAI被锁定在桥梁智能合约中。
        3. 在XDai侧铸造1 xDai原生代币的桥入口费,并分配到有效验证池(10个池中每个1 DAI = 1 xDai = 0.1 xDai)
        4. 其余的99 xDai通过xDai侧的智能合约铸造并发送到用户的地址。
        5. 用户进行大量交易,最终交易费用为.3 xDai。
          1. 交易费用在发生时累计。它们被发送到验证器(仅验证器,而不是委托者),负责密封发生事务的块。
          2. 完成后,用户想要返回主网并剩余90 xDAI:
            1. 8.7 xDai仍然在xDai DPOS链上,支付给其他人
            2. .3 xDai去交易费
            3. 1 xDai去了桥入场费
        6. 用户移除xDai DPOS链。xDai方面的桥梁智能合约提取出口费= .9 xDai。一旦提取费用,就会烧掉89.1 xDai。
        7. 桥出口费用分配给有效验证池(.9 xDai = .09 xDai,每个10个验证器池)
        8. 89.1 DAI在主网上的合约中解锁。

        提取的总费用:

      • 在桥入口1 xDai
      • .9 xDai在桥出口
      • .3交易费用xDai(为简单起见,我们说4个单独的验证员以相同的方式参与这些交易,gasPrice / gasLimit相等)

        收集的Validator奖励:

      • 验证者池1:0.19 xDai
        • 验证者:.0634 xDai(34%)+ .075 xDai交易费
        • 代表1:.0633 xDai(33%)
        • 代表2:.0633 xDai(33%)
      • 验证器池2:0.19 xDai
        • Validator = .057 xDai(30%)+ .075 xDai交易费
        • 代表:.133 xDai(70%)
      • 验证者池3 – 4:0.19 xDai
        • 验证者= 0.19 xDai + .075 xDai交易费
      • 验证器池5 – 10:0.19 xDai
        • 验证器= 0.19 xDai

          附录C:DPOS / ERC20到ERC20网桥示例场景

          假设:

      • 当前的验证人/委派人当选并已建立桥接DPOS令牌
      • 仅xDai DPOS链上的DPOS令牌的年通货膨胀率为1%
      • 大桥入场费为1%,移除费为1%
      • 对于所有赌注时期,相同的共识验证器都是活跃的。这是不现实的,但允许简化计算。
      • 本月赌注的DPOS ERC677总量为18,000,导致在1个月内分发的另外15个DPOS ERC677(18000个代币的1%除以12个月)。

        验证器池赌注:

      • 验证器池1:验证器1有100个DPOS,2个委托者每个有100个DPOS(总共300个)
      • 验证器池2:验证器2有100个DPOS,1个委托者有300个(总共400个)
      • 验证器池3:验证器3有200个DPOS和0个委托者(新委托者选择此池)
      • 验证器池4-10作为单个实体验证器启动,每个验证器具有500个DPOS。

        新的委托用户想要加入xDai DPOS链并投入一些令牌他们将100 DPOS传输到xDai DPOS链。

        1. 100 DPOS ERC20被发送到主网桥合约。
        2. 100 DPOS ERC20被锁定在桥智能合约中。
        3. 1个DPOS ERC677标记令牌(1%)的桥入口费用在xDai DPOS侧铸造并分配到有效验证池(1个DPOS ERC20 = 1 DPOS ERC677 = 0.1 DPOS ERC677,每个10个池)
        4. 其余的99 DPOS ERC677通过xDai侧的智能合约铸造并发送给代理商的地址。
        5. 委托人在Validator 3的池中投入了99个DPOS。
          1. 委托人不会收到当前赌注时期的任何奖励。但是,在下一个Staking时期,再次选出验证器3池,并且委托者开始累积奖励。
          2. 委托人仍然使用活动验证器池3进行4个刻度时期(1个月)。在月底,代理人发出股权撤回的信号。
            1. 在这个月中,10,000个额外的DPOS令牌需要支付入场/出境费。(可能还有其他的委托人并添加了验证器和验证器集更改,但为了简化示例计算,我们假设验证器/委托器集保持静态)。这意味着收取了100个DPOS费用(1%)。共有10个池,因此每个验证器池分配了10个DPOS。
            2. 在整个月中,通货膨胀率导致另外15个DPOS作为整体奖励分配。假设验证器集没有改变且所有验证器均等地参与,则将1.5 DPOS分配给每个池。
            3. 对于Validator池3,委托人拥有约33%的股份,并且共有11.5个令牌被添加到池中。这意味着委托人在一个月内收到了~3.79 DPOS ERC677代币。
        6. 委托人使用~102.79 DPOS ERC677令牌移除xDai DPOS链。xDai方面的桥梁智能合约提取1%移除费= ~1.02 DPOS ERC677。102.79 DPOS令牌被烧毁,1.02 DPOS令牌被铸造。
        7. 桥出口费用分配给主动验证池(1.02 DPOS ERC677 =.102个验证者池中的每个池的DPOS)
        8. 101.77(102.79 – 1.02)DPOS ERC20在主网上的合约中解锁。这是委托人在DPOS ERC20令牌中的新平衡。

        从代理人处提取的总费用:

      • 1桥上入口处的DPOS ERC677
      • 桥上出口处有1.02 DPOS ERC677

        收集的验证者池奖励(通过1个月,所有都是近似的并基于简单的假设):在这种情况下,在4个赌注时期的过程中,每个池都收到:

      • 10 DPOS ERC677作为桥梁出入境费
      • 1.5 DPOS ERC677作为令牌通胀
      • .10 DPOS ERC677用于示例委托方的桥接出口

        这导致以下近似分布:

      • 验证器池1:11.6 DPOS ERC677
        • 验证者:3.87 DPOS ERC677(33.4%)○代理人1:3.865 DPOS ERC677(33.3%)○代理人2:3.865 DPOS ERC677(33.3%)
      • 验证器池2:11.6 DPOS ERC677
        • 验证器= 3.48 DPOS ERC677(30%)
  • 代表:8.12 DPOS ERC677(70%)
  • 验证器池3:11.6 DPOS ERC677
    • 验证器= 7.81 DPOS ERC677(66.6%)
    • 代表:3.79 DPOS ERC677(33.3%) – 不包括.10移除费
  • 验证器池4 – 10:11.6 DPOS ERC677
    • 验证器= 11.6 DPOS ERC677

      附录D:DPOS建模

      我们使用NetLogo建模了DPOS共识参与者的行为[20]。该模型采用几个输入参数来约束建模算法的随机步骤:

      图片

      基本DPOS参数:

      • 验证器集的最大大小
      • 允许的最大候选人数量
      • 初始验证器集的大小
      • 候选人股份的最低金额(以赌注代币表示)
      • 块奖励(BR,以奖励代币表示)
      • 最小验证者奖励份额,以百分比表示
      • 用于踩踏模型的其他控制变量。

模型的每个步骤代表一个铆接时代。该模型抽象远离

赌注时期的实际持续时间。经过56个步骤(假设长达一周的模拟时期,实际建模大约一年)我们得到了以下网络参与者的传播:

  • 水平相对于赌注池的大小(从0到委托人到+无限)
  • 垂直方面,参与者增持的奖励(0到+无穷大)。图片从网络图中可以明显看出,与适当的委托人(蓝色)相比,奖励被分配给候选人(绿色和红色)的金额更大。这主要是因为有更多适当的代表(参与者没有成为候选人)而不是候选人。分析还显示,参与者按照他们在网络上花费的时间按比例获得奖励:图片

    其他网络统计

    图片

    “参与者”K线走势图显示所有参与者(黑人),代理人(蓝色),所有候选人(包括当前验证员(橙色)),排除当前验证员(绿色)的正确候选人的所有赌注时期(从0到56)的变化,以及目前的验证人(红色)。

    “奖励”K线走势图显示每个类别中参与者产生的奖励。

    “赌注”K线走势图显示参与者在这些类别中赌注的金额。

    此处提供了可手动配置值的工作模型。

    附录E:Honey Badger BFT(HBBFT)集成

    Honey Badger BFT(HBBFT)一致性算法允许分布式,可能异步环境中的节点实现事务协议。协议过程不需要领导节点,容忍损坏的节点,并在不利的网络条件下取得进展。有关更多信息,请参阅HBBFT github存储库

    我们目前正在将HBBFT与Parity Ethereum客户端集成,为POSDAO提供额外的共识选项。对奇偶校验的修改包括:

  • 区块协议流程:生成块之前,就建议的交易清单达成HBBFT共识。该列表由代理验证器提出的所有(或大多数)事务的并集组成,并且每个验证器创建相同的块。使用阈值签名协作签名该块。

  • RNG生成:HBBFT可以从仅在达到内容协议后显示的数字创建安全随机性。这种随机性可用于在Staking时期开始时选择新的验证器集,并作为智能合约的随机性的安全来源。

  • 块验证:需要接受使用阈值签名密封的块作为有效块。奇偶校验必须跟踪当前验证器集,以便将阈值签名与验证器集的主密钥相匹配。

  • 块创建:为了增加吞吐量,即使先前的块尚未被密封,也可以在确定前一块的事务后立即创建新块。

  • 治理合约交互:奇偶校验需要请求验证器集来确定验证器集更改,然后使用HBBFT来实施这些更改。奇偶校验还应向合约报告恶意验证器行为(故障报告)。

  • 验证器集更改/密钥生成:验证器集在多个块上转换,此过程需要一组新验证器的阈值密钥,这些密钥必须“在链上”生成(使用单独的智能合约)。

  • 网络:为了有效沟通,节点必须交易所低延迟,

    高带宽目标消息。验证器集更改时,新验证器必须建立彼此的直接连接。

  • 网络启动:必须将项目添加到链规范中,以便它们包含在创世块中。这包括编译的治理合约和公共主密钥。此外,必须在网络启动之前将相应的密钥份额分配给初始网络验证器(这可以在网络外部完成)。

参考

[1] de Vries, A (2018). Bitcoin’s growing energy problem. Joule, 2(5), 801-805. https://doi.org/10.1016/j.joule.2018.04.016

[2] J. Siim, “Proof-of-stake”, Research Seminar in Cryptography, 2017. https://courses.cs.ut.ee/MTAT.07.022/2017_fall/uploads/Main/janno-report-f17.pdf

[3] Saleh, F. (2018).区块链 Without Waste: Proof-of-Stake. SSRN Electronic Journal. 10.2139/ssrn.3183935.

[4] Iddo Bentov, Ariel Gabizon, and Alex Mizrahi (2014). 加密货币 without proof of work.

CoRR, abs/1406.5694. https://arxiv.org/pdf/1406.5694.pdf

[5] Buterin, V., and V. Griffith (2017). Casper the Friendly Finality Gadget. CoRR, https://arxiv.org/abs/1710.09437.

[6] AuRa (Authority Round) Consensus Engine https://wiki.parity.io/Aura

[7] Miller, A., Xia, Y., Croman, K., Shi, E., Song, D. (2016). The Honey Badger of BFT Protocols.

In: Cryptology ePrint Archive 2016/199 https://eprint.iacr.org/2016/199.pdf

[8] D. Larimer (2017). DPOS Consensus Algorithm – The Missing White Paper. https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper [9] V. Buterin (2014). A next-generation smart contract and decentralized application platform. https://github.com/ethereum/wiki/wiki/White-Paper

[10] Gazi P., Kiayias A., Russell A. (2018). Stake-Bleeding Attacks on Proof-of-Stake区块链s. 2018 加密货币Valley Conference on区块链 Technology (CVCBT), 85-92. https://allquantor.at/blockchainbib/pdf/gazi2018stake.pdf

[11] “Nothing at stake attack ethereum.” [Online]. Available: https://github.com/ethereum/wiki/wiki/Problems

[12] Li, W., Andreina, S., Bohli, J., Karame, G. (2017). Securing Proof-of-Stake区块链 Protocols. Data Privacy Management, 加密货币 and区块链 Technology. Springer, Cham, 297-315.

https://www.researchgate.net/publication/319647471_Securing_Proof-of-Stake_Blockchain_Pro tocols

[13] Kanjalkar, S., Kuo, J., Yunqi Li, Y. & Miller, A. (2019). Short Paper: I Can’t Believe It’s Not Stake! Resource Exhaustion Attacks on POS. Financial Cryptography 2019. http://fc19.ifca.ai/preproceedings/180-preproceedings.pdf

image

[14] “Fake Stake” attacks on chain-based Proof-of-Stake cryptocurrencies. [Online]. Available: https://medium.com/@dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrenci es-b8b05723f806

[15] Parinya Ekparinya, P., Gramoli, V., Jourjon, G. (2019). The Attack of the Clones against Proof-of-Authority. https://arxiv.org/abs/1902.10244

[16] Parinya Ekparinya, P., Gramoli, V., Jourjon, G. (2018). Impact of Man-In-The-Middle Attacks on Ethereum https://doi.org/10.1109/SRDS.2018.00012

[17] Randao: Verifiable Random Number Generation (2017) [Online]. Available:

https://randao.org/whitepaper/Randao_v0.85_en.pdf

[18] Alturki, M. & Rosu, G. (2018). Statistical Model Checking of RANDAO’s Resilience Against Pre-computed Reveal Strategies. https://www.ideals.illinois.edu/bitstream/handle/2142/102076/rdao-analysis.pdf

[19] GencerA.E.BasuS.EyalI.vaRenesseR.SirerE.(2018)DecentralizatioiBitcoianEthereuNetworkshttps://arxiv.org/pdf/1801.03998.pdf

[20] NetLogo. https://ccl.northwestern.edu/netlogo/

本网站使用Cookies来改善你的体验。 我们假设你对此感到满意,但如果你愿意,可以选择移除。 接受 阅读更多