Editing Block producer DAO (section)

== Code ==
The following two stages illustrate the basic algorithm for creating a BpDAO.  

=== Workflow ===


The first stage, given by the first sequence diagram and pseudocode illustrates basic [[DAO Governance Framework#DGF workflow|DGF flow]] applied to block production. This is PoR, i.e., Proof of REP. [[File:BPSeqDiag.png|center|thumb|890x890px]]

<syntaxhighlight lang="text" style="font-size:100%" line="1">
Block Production Algorithm Pseudo-code

Inputs: dynamic set of desired transactions from customers

Output: a blockchain of settled transactions
__________

Definitions

REP := reputation token

$ := currency token

wallet := program for holding tokens for an individual participant

Tx := transaction sending a currency token from one wallet to another


customer := has
  * unique identifying address
  * wallet for holding $ and sending Txs

block producer := has
  * unique identifying address
  * wallet for receiving $ and REP 
  * ability to give inputs to ASC, WSC, & VPSC


ASC := Availability Smart Contract 

WSC := Work Smart Contract

VPSC := Validation Pool Smart Contract

Forum := database holding history of blocks & Validation Pool results

gossip network := set of all active Tx held by block producers

Validation Pool := dynamically changing set of block producers who are currently policing a proposed block
__________
Algorithm

For i = 1 to infinity

  Produce block  i :=        {

    WSC function:= {
      * listens to active ASCs
      * pseudorandomly selects 1 block producer based on weights of encumbered REP in ASCs
      * announces current block producer
      * takes current block producer's REP from ASC
      * waits for a set of Txs from current block producer
      * produces a block        
      * publishes proposed block to Forum
      * sends 4 things to the VPSC:
        1. $ from Txs 
        2. new $ minted in block
        3. block producer's REP from ASC
        4. address of proposed block 
                   }


    VPSC function: := {
      * mints REP tokens in proportion to $ tokens
      * announces new validation pool and proposed block address to block producers 
      * collects votes from block producers
      * tallies votes to determine distribution of new REP tokens
      * distributes new REP
      * distributes REP salary
      * publishes vote results to Forum
          [Forum signals to Tx status to customer]
      * signals WSC to produce next block             
                      }
                                 }
</syntaxhighlight>

=== Reference mechanism ===
The next sequence diagram illustrates the reference mechanism, which provides a means of bootstrapping governance by making proposals which cite older proposals. This gives an incentive mechanism for a community to organically improve the block producer protocols. 
[[File:RefMechanismSeqDiag2.png|center|thumb|848x848px]]  

For example, to improve the consensus mechanism WSC, the idea is to evolve the conversation in 4 phases.  

In Phase 1, people chat about improvements they would like to see.  

In Phase 2, a collection of improvement proposals are offered. Improvement proposals cite older proposals that they build on (detailed in the second sequence diagram, above). Improvement proposals are continually made, in perpetuity. 

In Phase 3, the latest favored proposal will become the active WSC, ''de facto'' because it is used by the group. The active WSC primarily rewards the worker whose ASC is selected with the newly minted REP. Secondarily the WSC sends part of this REP reward to the author of the WSC. The sub-DAG of proposals connected by references to the currently favored proposal will all be rewarded with REP and subsequently $. Proposals not connected with references are not rewarded.   

In Phase 4, a new type of REP is invented, called gREP,  to promote active, explicit, on-chain governance of the Block producer DAO. The active WSC will be changed to include a line sharing a percentage of the monetary rewards for block production as gREP salary. Owners of gREP use it for legislative governance, i.e., to make proposals (the work of the governance wing of the DAO) and to vote on which proposals are canonized by binding validation pools using gREP. The amount set aside for governance is a continual negotiation between block producers (wREP holders), and governors (gREP holders), who will typically overlap to some degree. That amount is the dev budget.  

In summary, the means by which a community creates a DAO using DGF is to engender two systems: DGF flow (for executive governance) and the reference mechanism (for legislative governance).