Editing DAO Governance Framework (section)

== Key Concepts ==

=== Reviews ===
''Main pages: [[Governance#Executive governance|Executive governance]] & [[Judicial governance]]''

A goal of the DAO is to deliver quality results to its customers. To achieve this, experts submit work products for review by other experts within the DAO. This is executive governance which is implemented through the [[Validation Pool]] mechanism. These reviews, as well as the review process itself, are subject to future review under judicial governance which is implemented primarily through [[Forum reference mechanisms]]. This ability to consciously review (judicially) the unconscious review (executive) is complicated, but is necessary to guarantee one of the key aspects of reputation are meaninfully embodied in REP tokens. That is, a member's reputation can be diminished or augmented in the future based on how well their behavior adheres to the DAO's values.

=== Governance ===
''Main page: [[Governance]]''

The MVPR parameters are designed to allow [[Governance#Legislative governance|customization]] of the rules that govern the operations of the DAO. 

=== Reputation ===
''Main page: [[Reputation]]''

DAO participants shall be awarded with reputation tokens for contributions which the other DAO members deem valuable. 

Reputation token types should be specific to the [[Reputation#6. Limited Domain|relevant domain]] of action. For instance, a typical primary DAO begins with three distinct kinds of reputation:
*'''REP''' - Work product reputation
*'''gREP''' - Governance reputation
*'''cREP''' - Comment reputation 

REP is associated with a work product. When members do work directly with the public they receive REP tokens. Usually, REP value is minted in proportion to the fees the worker earned for the DAO. 

gREP is associated with proposals to modify the DAO's governance parameters. This is what we consider governance of the hard protocols in the system. gREP may be staked toward new proposals. Successful proposals shall attribute new gREP to their authors and supporters. It is likely that there will be a close relationship between gREP and REP since successful workers will likely have the best understanding about how to improve a DAOs protocols for work. In this case there is no need for a distinction in many DAOs.

cREP plays an important role in the [[Governance#Soft protocols|soft protocols]] governing the organization. Fundamentally a DAO is a group of individuals. Their behavior will be shaped partly by the communication that occurs among them. Comments will be a central vehicle for this communication. Each organization may develop its own ways of associating meaning with comments. An organization may want its participants to be able to stake their own reputation toward promoting particular comments, and toward suppressing others. Our goal is to enable each community to articulate its own values, in a way that is transparent for the community as well as the public to observe.

cREP is the most difficult REP token to valuate. A typical comment will likely be submitted without any associated cash fees when they are first posted in the Forum. DGF has options for DAO founders for making an initial protocol for valuing such tokens which do not have the grounding value of cash money. For instance a variation on the [[wikipedia:PageRank|PageRank algorithm]] can be used to weight the Forum's WDAG based solely on the strength of edges without requiring weights of nodes. However, before any type of REP token is grounded with the concrete meaning gained by being associated with money, the system is particularly susceptible to gaming. The basic PageRank algorithm, for instance, can be gamed by spamming the Forum with self-referential posts driven by [[wikipedia:Sock_puppet_account|sockpuppets]].

=== Distributed computing perspective ===
Since a primary DAO is an open permissionless decentralized network, Byzantine resistance is the primary design consideration. Any network node has the ability to spam the network with any information they choose. A Byzantine node cannot be prevented from editing any software it uses before communicating with the network. So a decentralized network's protocols must involve checking every message for consistency and integrity. The only defense against such behavior is to ignore Byzantine messages that don't accurately encumber valuable tokens or to slash the tokens encumbered in a Byzantine message which does encumber tokens.  

For instance, in DGF workflow, we assume every full node in the network behaves in a similar manner to a full client in the Ethereum network. In Ethereum, a full node participates in the distributed computing architecture called [https://ethereum.org/en/developers/docs/evm/ EVM] as follows. The node first downloads the entire history of the blockchain – every transaction (TX), every smart contract (SC), every record of how much ether was submitted to run each smart contract, and every output of every smart contract so engaged. A full node has its own database of the entire collection of all ERC20 (and ERC471, etc.) tokens that have ever been minted and their complete history. A full node refers to this information to determine the validity of every TX request to fulfill a new transaction on the Ethereum network. This means that any Byzantine action is ignored or punished according to protocols that have previously been established by the Ethereum network.

By analogy with Ethereum's EVM flow, in DGF a full node downloads the entire history of the DAO (the Forum) and parses the value of every REP token, in order of creation, by calculating their values according to the changing rules whose history is encoded in the Forum. A record of every successful Validation Pool is required, as well as the rules for what is a successful Validation Pool at the time it was called. For instance, a Validation Pool has a quorum necessary for it to be considered a canonical instantiation that leads to its inclusion in the Forum. The quorum will change as the DAO evolves. The larger and more decentralized that the DAO becomes, the smaller the quorum needs to be in order to maintain security against Byzantine actions.

This counter-intuitive perspective of maximally redundant computation is necessary to maintain the decentralized structure of the network in the inevitable presence of Byzantine actors.

=== Notes about Implementation ===
These reputation mechanisms will be encoded as smart contracts. Such contracts run on a block chain and thus provide a resilient, distributed ledger where we can store the records of group participant activities.

It will be necessary to build software tooling that is capable of constructing a consensus view of the state of the DAO. This will need to access block-chain data encoded by the smart contract(s) as they ran at the time each block was written. The smart contracts themselves may change over time. Our goal is to encode these changes such that it is possible to reconstruct the entire computational history of the DAO. To maximize the flexibility of our initial contract, we will implement a set of hyper-parameters. In other words, the smart contract will express a dynamic algorithm; by changing the parameters of the algorithm, the behavior of the algorithm can be modified.

Broadly speaking, upgrading the underlying smart contract itself produces a hard fork. The best case for such a scenario is that the new contract is (sufficiently) compatible with the previous, and that all participants are able to upgrade to the new version in a (sufficiently) timely fashion. A design consideration for this project will be to attempt to reduce the probable costs of such a hard fork, by introducing some kind of internal versioning scheme for the blockchain code and data. TODO: Articulate the relative weight of this forward-compatibility consideration versus the competing design goal of avoiding excess complexity.