github.com/hyperledger/burrow@v0.34.5-0.20220512172541-77f09336001d/docs/reference/bonding.md (about)

     1  # Bond / Unbond
     2  
     3  Burrow adopts the notion of Bonded Proof-of-Stake (BPoS). This means that in order to 
     4  participate in consensus, a node must give some value of its token as collateral. 
     5  The more token that is bonded, the higher the chance of 'mining' a block.
     6  
     7  ## How it Works
     8  
     9  When starting a burrow node, we provide an address which links to an owned key-pair.
    10  Each running node thus has an identity which may active in the validator set. Assuming we have
    11  connected to a network, our node will replay state downloaded from its peers - from which we will
    12  be able to discern any native token stored at our address. If this amount is non-negligible
    13  we can submit a signed BondTx to be gossiped amongst the current validators who should include it
    14  in a block. When executing this transaction against our global state, burrow will first check that the 
    15  input address has correctly signed the payload, that the respective account exists with the bonding
    16  permission and has enough token to stake. If successful, then this will subtract the token from the
    17  account and raise the new validators power - enabling it to vote and propose new blocks. The procedure 
    18  for unbonding is antithetical, diminishing the validator accounts power on success.
    19  
    20  One nuance with altering the validator set is to do with a concept we call the 'max flow'.
    21  To prevent the validator pool changing too quickly over a single block whilst ensuring the 
    22  majority of validators are non-byzantine after the transition, we allow up to `ceil((t)/3) - 1`
    23  to be changed where `t` is the current total validator power.
    24  
    25  ## Future Work
    26  
    27  Currently a validator must bond or unbond themselves directly - we enforce a strict relationship 
    28  that prohibits staking token to another account. Funds may be send to another account however, 
    29  and providing that also has permission to bond, then it may join the validator set. In the future we
    30  hope to extend our model to allow for delegation, whereby any party with native token may stake it
    31  against a running validator and receive a share of the rewards.