Block producer DAO

DGF is used to make Block producer DAOs (BpDAOs) which govern block production in blockchains. These BpDAOs consist of members who earn REP tokens for producing canonical blocks and governing the development of the system. The REP minting mechanism of DGF incentivizes faithful production of blocks with a consensus mechanism called Proof of Reputation (PoR). DAO governance guides and rewards improvements to the platform.

Overview

A fork of Ethereum (or any other blockchain) with the original consensus mechanism initiates the new blockchain. The difference between an original blockchain consensus mechanism and a DGF variation is in governance. The fees are in the native token, initially ETH in the case of an Ethereum fork. Then REP is minted when a block is produced. Distribution of REP and ETH fees follow DGF flow:

1. A block producer is a holder of REP. A producer signals their availability to produce blocks by encumbering their REP in the availability smart contract (ASC).
2. Previous blocks pseudorandomly select a producer from the active ASCs.
3. The selected producer follows the current protocol for block production which is encoded in the current work smart contract (WSC).
4. When the block is finished it is posted to the Forum with the fees collected from the block, opening a Validation Pool (VPSC):
   1. The fees include any transaction fees and any production taxes--meaning newly minted ETH from that block.
   2. The VPSC mints new REP in proportion to the fees and encumbers the REP appropriately--default is 50% for the producer, 50% against the producer.
   3. The Bench of experts evaluate the block and stake their REP on the outcome.
   4. VPSC resolves the vote, distributing the REP to the winners in proportion to their stakes.
   5. VPSC distributes the fees to all members of the DAO in proportion to their REP holdings (REP salary).
5. Repeat

Code

Sequence diagram

Pseudocode

Inputs: 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:= {

WSC listens to active ASCs

WSC pseudorandomly selects 1 block producer based on weights of encumbered REP in ASCs

WSC announces current block producer

WSC takes current block producer's REP from ASC

WSC waits for a set of Txs from current block producer

WSC produces a block

WSC publishes proposed block to Forum

WSC 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: := {

VPSC mints REP tokens in proportion to $ tokens

VPSC announces new validation pool and proposed block address to block producers

VPSC collects votes from block producers

VPSC tallies votes to determine distribution of new REP tokens

VPSC distributes new REP

VPSC distributes REP salary

VPSC publishes vote results to Forum

[Forum signals to Tx status to customer]

VPSC signals WSC to produce next block

VPSC

VPSC

}

}

Variations

There are many improvements possible on the basic outline given above. DGF provides an evolutionary structure with incentives to continually improve the system. This is necessary for any PoS consensus mechanism, given the inevitable threat of gaming any cooperative system leads to an arms race of attack and defense as the system becomes more successful and valuable.

In this section we give an introduction to areas that will be continually improved.

Block Producer selection

At Step 2 in the above process, the block producer is pseudo-randomly selected from the active Availability Smart Contracts. If this is not done carefully, a Byzantine actor who is the latest active block producer can anticipate the pseudo-randomness and manipulate the algorithm so that he is selected again, in perpetuity, which would destroy the decentralization of the blockchain.

To guarantee the pseudo-random selection mechanism is resistant to such capture, there are several algorithms available. Here we detail a basic approach.

The problem of deciding how to write the pseudorandom