github.com/hyperledger/burrow@v0.34.5-0.20220512172541-77f09336001d/docs/ADRs/adr-3_bonding-natives.md (about)

     1  ---
     2  adr: 3
     3  title: Smart Contract Bonding Natives
     4  author: Silas Davis (@silasdavis), Gregory Hill (@gregdhill)
     5  discussions-to: https://chat.hyperledger.org/channel/burrow-contributors
     6  status: Draft
     7  type: Standards Track
     8  category: State, Consensus, Governance
     9  created: 2019-07-08
    10  ---
    11  
    12  ## Abstract
    13  
    14  In vanilla proof-of-stake, an account with some amount of token pledges to vest a portion of this to actively participate in consensus with the knowledge that
    15  misbehavior could result in punishment - bonded power is slashed to some extent. [PR 1100](https://github.com/hyperledger/burrow/pull/1100) contains the base
    16  implementation to support this model, but we foresee techniques such as delegation being important to network users in the future. Therefore, we propose a 
    17  smart contract orientated approach which leverages SNatives to expose 'admin' functionality for controlling individual validator investments.
    18  
    19  ## Motivation
    20  
    21  There are countless ways to model token economics, even in Proof-of-Stake (PoS) there are a number of schemes such as delegation, nomination or even hybrid
    22  approaches. It is conceivable that we may want to incorporate alternate methods in the future without forking which (depending on the technique) may not be
    23  easily done. Outsourcing this task to individual validators makes sense in the same way we do not control how native accounts move and use their tokens.
    24  
    25  ## Specification
    26  
    27  A management contract should sit at the address of each validator bonded onto the network which contains the logic for how that validator may operate. For instance,
    28  delegation would be trivial to implement if we could simply transfer funds to this account and have the smart contract automatically bond them. This special account
    29  then handles the validators portfolio at its discretion, simplifying our consensus overhead with a tight account to validator binding. 
    30  
    31  1. Account w/ bond permission signs and sends BondTx
    32      - (Optionally) add EVM / WASM bytecode
    33  2. Bond given amount for account into validator set
    34  3. Call against validator address checks for existence of code and executes 
    35  4. Exposed natives verify validator address / power and run directly against state, updating or removing power
    36  
    37  We would still like to maintain the notion of validator 'flow' to ensure that the set does not change too quickly. Additionally, if power is ever depleted then we
    38  may want to consider whether we should retain the contract. This problem also lends itself to upgradeability as a poorly written contract could severely impact the
    39  lifetime and reputation of the identity in question. One possible solution is to hard-code the special validator contract and make it a concern of the network - 
    40  upgradeable through governance / proposals. This has the benefit of equalizing all validators on a per-chain basis and makes patching vulnerabilities easier.