DGF
/
dao-governance-framework
6
0
Fork 0
Code Issues 7 Pull Requests Packages Projects Releases Wiki Activity

[SD-5] MVPR Architecture: CRDAO #5

New Issue
Open
opened 2022-09-18 22:54:37 -05:00 by laddhoffman · 14 comments
laddhoffman commented 2022-09-18 22:54:37 -05:00 (Migrated from gitlab.com)
Copy Link

Code Review DAO (CRDAO)

Summary

CRDAO is a collection of associates who vote on decisions and accrue reputation tokens for their participation.

The intent is to form a self-governing, autonomous agency, which in this case serves the function of performing code reviews.

Reputation tokens are awarded for successful participation.

Voting power is determined by reputation tokens.

Voters may initiate and participate in votes. Types of vote include code reviews, and internal governance proposals such as onboarding, KYC review, and parameter value changes.

The forum can serve as the vehicle through which these code reviews and other proposals are submitted, discussed, and tracked. The forum is a collection of posts, which may reference one another. In the abstract, (#3) this collection of posts can be a graph with arbitrary edges. In this particular implementation, as a starting point, the edges will correspond to the traditional forum structure of Post, Comment, Up/Down Vote.

Details

CRDAO currently (2022-09-18) includes 5 core contracts and 5 voter contracts.

Core contracts:

  • Admin
  • Reputation Token
  • Variable Repository
  • KYC Token
  • VA Token

Voter contracts:

  • Reputation
  • Simple
  • Repo
  • KYC
  • Onboarding

We propose to add 4 new Forum-related contracts:

  • Forum
  • Post
  • Validator
  • Upvoter

Forum

The forum contract will maintain a list of all validated posts.

The on-chain Forum contract provides an access point from which to browse the posts.

To minimize on-chain costs the amount of data in the Forum contract should be minimized.

Additional layers of metadata may be stored off-chain, such as in IPFS.

Post

Creating a post mints new reputation.

  • The reputation is only awarded if a vote passes in the validation pool.
    This will occur via the Validator voting contract.

A VA may submit a post by staking reputation.

An outsider may submit a post by paying a fee.

Each post must reference a Forum contract.

The reputation stake, or fee, will pay to add a Post to a Forum.

A comment is also a post. It may have a lower associated fee or reputation stake.

Upvoter

Like a comment, the upvote is linked to a parent Post.

Also like a comment, the upvote is a Post.

The Upvoter contract requires a reputation stake or a fee.

If multiple Upvotes pertain to the same Post, they should function as votes.

  • The winning side is awarded the reputation staked by the losing side.

Validator

Inputs to a Validator vote:

  • Results of off-chain computations for reputation awards
  • Reputation stake

When a Validator vote passes, the reputation minted by the target post is subdivided among the post's:

  • Author
  • Cited posts
  • Upvoted comments

Interaction of Validator and Forum

When a validator vote passes, the forum contract applies the results, distributing the resulting reputation awards.

  • The reputation tokens were minted when each post was created, and held in escrow until this moment.

Because these awards can be expensive to compute, they should be computed off-chain by the VA client software.

This off-chain computation will need to source data from the on-chain Post contracts.

The results of the computations should be submitted to a Validator contract as part of a vote.

IPFS

Clients should be able to obtain from the Forum contract, the list of posts above a certain reputation threshold.

The clients can use this to participate in IPFS pinning.

Under this model, as long as there are enough active DAO client nodes and IPFS nodes in operation, IPFS can function as a reliable store for off-chain data, such as metadata indices, appendices, datasets, code, media, etc.

This could provide a layer for the forum, allowing more comments to be posted and made visible to other clients without paying blockchain fees. Comments can be transcribed as posts to the blockchain when their value is deemed sufficient.

Code Review DAO (CRDAO) # Summary CRDAO is a collection of associates who vote on decisions and accrue reputation tokens for their participation. The intent is to form a self-governing, autonomous agency, which in this case serves the function of performing code reviews. Reputation tokens are awarded for successful participation. Voting power is determined by reputation tokens. Voters may initiate and participate in votes. Types of vote include code reviews, and internal governance proposals such as onboarding, KYC review, and parameter value changes. The forum can serve as the vehicle through which these code reviews and other proposals are submitted, discussed, and tracked. The forum is a collection of posts, which may reference one another. In the abstract, (#3) this collection of posts can be a graph with arbitrary edges. In this particular implementation, as a starting point, the edges will correspond to the traditional forum structure of Post, Comment, Up/Down Vote. # Details CRDAO currently (2022-09-18) includes 5 core contracts and 5 voter contracts. Core contracts: - Admin - Reputation Token - Variable Repository - KYC Token - VA Token Voter contracts: - Reputation - Simple - Repo - KYC - Onboarding We propose to add 4 new Forum-related contracts: - Forum - Post - Validator - Upvoter ## Forum The forum contract will maintain a list of all validated posts. The on-chain Forum contract provides an access point from which to browse the posts. To minimize on-chain costs the amount of data in the Forum contract should be minimized. Additional layers of metadata may be stored off-chain, such as in IPFS. ## Post Creating a post mints new reputation. - The reputation is only awarded if a vote passes in the validation pool. This will occur via the Validator voting contract. A VA may submit a post by staking reputation. An outsider may submit a post by paying a fee. Each post must reference a Forum contract. The reputation stake, or fee, will pay to add a Post to a Forum. A comment is also a post. It may have a lower associated fee or reputation stake. ## Upvoter Like a comment, the upvote is linked to a parent Post. Also like a comment, the upvote is a Post. The Upvoter contract requires a reputation stake or a fee. If multiple Upvotes pertain to the same Post, they should function as votes. - The winning side is awarded the reputation staked by the losing side. ## Validator Inputs to a Validator vote: - Results of off-chain computations for reputation awards - Reputation stake When a Validator vote passes, the reputation minted by the target post is subdivided among the post's: - Author - Cited posts - Upvoted comments ## Interaction of Validator and Forum When a validator vote passes, the forum contract applies the results, distributing the resulting reputation awards. - The reputation tokens were minted when each post was created, and held in escrow until this moment. Because these awards can be expensive to compute, they should be computed off-chain by the VA client software. This off-chain computation will need to source data from the on-chain Post contracts. The results of the computations should be submitted to a Validator contract as part of a vote. # IPFS Clients should be able to obtain from the Forum contract, the list of posts above a certain reputation threshold. The clients can use this to participate in IPFS pinning. Under this model, as long as there are enough active DAO client nodes and IPFS nodes in operation, IPFS can function as a reliable store for off-chain data, such as metadata indices, appendices, datasets, code, media, etc. This could provide a layer for the forum, allowing more comments to be posted and made visible to other clients without paying blockchain fees. Comments can be transcribed as posts to the blockchain when their value is deemed sufficient.
laddhoffman commented 2022-09-18 22:54:38 -05:00 (Migrated from gitlab.com)
Copy Link

assigned to @laddhoffman

assigned to @laddhoffman
laddhoffman commented 2022-09-18 23:17:51 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
laddhoffman commented 2022-09-18 23:26:52 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
laddhoffman commented 2022-09-19 00:08:28 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
laddhoffman commented 2022-09-19 00:09:07 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
laddhoffman commented 2022-09-19 00:12:41 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
laddhoffman commented 2022-09-19 13:57:37 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
laddhoffman commented 2022-09-19 13:58:06 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
laddhoffman commented 2022-09-23 14:45:56 -05:00 (Migrated from gitlab.com)
Copy Link

Comments in this thread will represent snapshots of the draft proposal, as checkpoints for reference.

Motivation:
Provide a record so that readers can reference a version of the document they may have previously viewed.

Comments in this thread will represent snapshots of the draft proposal, as checkpoints for reference. Motivation: Provide a record so that readers can reference a version of the document they may have previously viewed.
laddhoffman commented 2022-09-23 14:47:45 -05:00 (Migrated from gitlab.com)
Copy Link

Snapshot

Code Review DAO (CRDAO)

Summary

CRDAO is a collection of associates who vote on decisions and accrue reputation tokens for their participation.

The intent is to form a self-governing, autonomous agency, which in this case serves the function of performing code reviews.

Reputation tokens are awarded for successful participation.

Voting power is determined by reputation tokens.

Voters may initiate and participate in votes. Types of vote include code reviews, and internal governance proposals such as onboarding, KYC review, and parameter value changes.

The forum can serve as the vehicle through which these code reviews and other proposals are submitted, discussed, and tracked. The forum is a collection of posts, which may reference one another. In the abstract, (#3) this collection of posts can be a graph with arbitrary edges. In this particular implementation, as a starting point, the edges will correspond to the traditional forum structure of Post, Comment, Up/Down Vote.

Details

CRDAO currently (2022-09-18) includes 5 core contracts and 5 voter contracts.

Core contracts:

  • Admin
  • Reputation Token
  • Variable Repository
  • KYC Token
  • VA Token

Voter contracts:

  • Reputation
  • Simple
  • Repo
  • KYC
  • Onboarding

We propose to add 4 new Forum-related contracts:

  • Forum
  • Post
  • Validator
  • Upvoter

Forum

The forum contract will maintain a list of all validated posts.

The on-chain Forum contract provides an access point from which to browse the posts.

To minimize on-chain costs the amount of data in the Forum contract should be minimized.

Additional layers of metadata may be stored off-chain, such as in IPFS.

Post

Creating a post mints new reputation.

  • The reputation is only awarded if a vote passes in the validation pool. This will occur via the Validator voting contract.

A VA may submit a post by staking reputation.

An outsider may submit a post by paying a fee.

Each post must reference a Forum contract.

The reputation stake, or fee, will pay to add a Post to a Forum.

A comment is also a post. It may have a lower associated fee or reputation stake.

Upvoter

Like a comment, the upvote is linked to a parent Post.

Also like a comment, the upvote is a Post.

The Upvoter contract requires a reputation stake or a fee.

If multiple Upvotes pertain to the same Post, they should function as votes.

  • The winning side is awarded the reputation staked by the losing side.

Validator

Inputs to a Validator vote:

  • Results of off-chain computations for reputation awards
  • Reputation stake

When a Validator vote passes, the reputation minted by the target post is subdivided among the post's:

  • Author
  • Cited posts
  • Upvoted comments

Interaction of Validator and Forum

When a validator vote passes, the forum contract applies the results, distributing the resulting reputation awards.

  • The reputation tokens were minted when each post was created, and held in escrow until this moment.

Because these awards can be expensive to compute, they should be computed off-chain by the VA client software.

This off-chain computation will need to source data from the on-chain Post contracts.

The results of the computations should be submitted to a Validator contract as part of a vote.

IPFS

Clients should be able to obtain from the Forum contract, the list of posts above a certain reputation threshold.

The clients can use this to participate in IPFS pinning.

Under this model, as long as there are enough active DAO client nodes and IPFS nodes in operation, IPFS can function as a reliable store for off-chain data, such as metadata indices, appendices, datasets, code, media, etc.

This could provide a layer for the forum, allowing more comments to be posted and made visible to other clients without paying blockchain fees. Comments can be transcribed as posts to the blockchain when their value is deemed sufficient.

Snapshot <details> Code Review DAO (CRDAO) # Summary CRDAO is a collection of associates who vote on decisions and accrue reputation tokens for their participation. The intent is to form a self-governing, autonomous agency, which in this case serves the function of performing code reviews. Reputation tokens are awarded for successful participation. Voting power is determined by reputation tokens. Voters may initiate and participate in votes. Types of vote include code reviews, and internal governance proposals such as onboarding, KYC review, and parameter value changes. The forum can serve as the vehicle through which these code reviews and other proposals are submitted, discussed, and tracked. The forum is a collection of posts, which may reference one another. In the abstract, (#3) this collection of posts can be a graph with arbitrary edges. In this particular implementation, as a starting point, the edges will correspond to the traditional forum structure of Post, Comment, Up/Down Vote. # Details CRDAO currently (2022-09-18) includes 5 core contracts and 5 voter contracts. Core contracts: * Admin * Reputation Token * Variable Repository * KYC Token * VA Token Voter contracts: * Reputation * Simple * Repo * KYC * Onboarding We propose to add 4 new Forum-related contracts: * Forum * Post * Validator * Upvoter ## Forum The forum contract will maintain a list of all validated posts. The on-chain Forum contract provides an access point from which to browse the posts. To minimize on-chain costs the amount of data in the Forum contract should be minimized. Additional layers of metadata may be stored off-chain, such as in IPFS. ## Post Creating a post mints new reputation. * The reputation is only awarded if a vote passes in the validation pool. This will occur via the Validator voting contract. A VA may submit a post by staking reputation. An outsider may submit a post by paying a fee. Each post must reference a Forum contract. The reputation stake, or fee, will pay to add a Post to a Forum. A comment is also a post. It may have a lower associated fee or reputation stake. ## Upvoter Like a comment, the upvote is linked to a parent Post. Also like a comment, the upvote is a Post. The Upvoter contract requires a reputation stake or a fee. If multiple Upvotes pertain to the same Post, they should function as votes. * The winning side is awarded the reputation staked by the losing side. ## Validator Inputs to a Validator vote: * Results of off-chain computations for reputation awards * Reputation stake When a Validator vote passes, the reputation minted by the target post is subdivided among the post's: * Author * Cited posts * Upvoted comments ## Interaction of Validator and Forum When a validator vote passes, the forum contract applies the results, distributing the resulting reputation awards. * The reputation tokens were minted when each post was created, and held in escrow until this moment. Because these awards can be expensive to compute, they should be computed off-chain by the VA client software. This off-chain computation will need to source data from the on-chain Post contracts. The results of the computations should be submitted to a Validator contract as part of a vote. # IPFS Clients should be able to obtain from the Forum contract, the list of posts above a certain reputation threshold. The clients can use this to participate in IPFS pinning. Under this model, as long as there are enough active DAO client nodes and IPFS nodes in operation, IPFS can function as a reliable store for off-chain data, such as metadata indices, appendices, datasets, code, media, etc. This could provide a layer for the forum, allowing more comments to be posted and made visible to other clients without paying blockchain fees. Comments can be transcribed as posts to the blockchain when their value is deemed sufficient. </details>
laddhoffman commented 2022-09-23 14:48:19 -05:00 (Migrated from gitlab.com)
Copy Link

So far we've talked about the interactions between the Validation pool and the Forum.
The model we have for our generic MVRP architecture includes two more smart contracts,
an Availability contract and a Business contract.

The Availability contract

  • Lets associates stake reputation to indicate readiness to receive work requests

The Business contract

  • Accepts fees from outsiders to initiate a work request
  • Assigns the request to an available associate
  • Lets the associate submit their results to be discussed in the Forum and voted by the Validation pool
So far we've talked about the interactions between the Validation pool and the Forum. The model we have for our generic MVRP architecture includes two more smart contracts, an Availability contract and a Business contract. The Availability contract - Lets associates stake reputation to indicate readiness to receive work requests The Business contract - Accepts fees from outsiders to initiate a work request - Assigns the request to an available associate - Lets the associate submit their results to be discussed in the Forum and voted by the Validation pool
laddhoffman commented 2022-09-26 11:13:47 -05:00 (Migrated from gitlab.com)
Copy Link

Key Points

Why do we need a Forum?

  • In order for the DAO to decide contentious issues, we need a discussion period preceding each vote.
  • We want this discussion to be transparent, i.e. publicly visible, and to form a record that may be referenced later.
  • We want to incentivise participation in the discussion, by awarding reputation to contributors.
  • We want to protect the integrity of this discussion by requiring reputation stakes for good-faith participation.

Why do we need part of the Forum to be off-chain?

  • It would be too expensive to store the entire content of each post on-chain.
    Therefore off-chain storage is required.
  • It would be too expensive to call an on-chain contract for every new post.
    Therefore off-chain transaction batching is required.

How will we secure the off-chain Forum nodes?

  • DAO-approved Forum node software should be determined by on-chain voting.
    Forum node operators should verify this hash before deploying their forum node.
  • Forum node will accept connections from user agents such as web clients.
    Clients will be authenticated by signing a message with their reputation-holding key.
  • Network nodes must vote on-chain to validate their results.

What are the storage requirements for the off-chain Forum?

  • Any corruption of the off-chain forum data would present an attack vector against the DAO.
    Therefore we should avoid centralizing this off-chain storage.
    Existing decentralized storage systems can form a part of this solution. i.e. IPFS, filecoin, Arweave, etc.
  • In addition to archival storage solutions like IPFS, etc,
    each forum node will also need access to an operational database.
    This will provide the ability to maintain indices, relations, and materialized views,
    necessary for serving data to clients and for processing incoming client actions.

Why do we need messaging among the off-chain Forum?

  • Different clients may connect to different Forum nodes.
    We want each client to be notified when other clients perform actions in the Forum.
  • Forum nodes already need public addresses to accept connections from clients.
    We can use this to enable Forum nodes to connect to each other as well.
  • Unless we want to rely on a third-party hosted operational database,
    we need messaging among Forum nodes to support the consensus protocol for a distributed operational database.

What are the on-chain dependencies for the off-chain Forum?

  • Reputation: Forum network will rely on reputation tokens, awarded by on-chain validation pool,
    in order to secure communications in the off-chain network.
  • Forum Validator: Forum nodes will use a voting contract to enact reputation effects on-chain.
  • Network Node: Associates will need to stake reputation to register network nodes.
  • Funding: Network nodes will have to pay blockchain transaction fees.
    We can use a smart contract to receive fees for this purpose.
    This can function as an investment vehicle. Funders can be paid back when the DAO receives payments from other sources.
Key Points --- ## Why do we need a Forum? - In order for the DAO to decide contentious issues, we need a discussion period preceding each vote. - We want this discussion to be transparent, i.e. publicly visible, and to form a record that may be referenced later. - We want to incentivise participation in the discussion, by awarding reputation to contributors. - We want to protect the integrity of this discussion by requiring reputation stakes for good-faith participation. ## Why do we need part of the Forum to be off-chain? - It would be too expensive to store the entire content of each post on-chain. Therefore off-chain storage is required. - It would be too expensive to call an on-chain contract for every new post. Therefore off-chain transaction batching is required. ## How will we secure the off-chain Forum nodes? - DAO-approved Forum node software should be determined by on-chain voting. Forum node operators should verify this hash before deploying their forum node. - Forum node will accept connections from user agents such as web clients. Clients will be authenticated by signing a message with their reputation-holding key. - Network nodes must vote on-chain to validate their results. ## What are the storage requirements for the off-chain Forum? - Any corruption of the off-chain forum data would present an attack vector against the DAO. Therefore we should avoid centralizing this off-chain storage. Existing decentralized storage systems can form a part of this solution. i.e. IPFS, filecoin, Arweave, etc. - In addition to archival storage solutions like IPFS, etc, each forum node will also need access to an operational database. This will provide the ability to maintain indices, relations, and materialized views, necessary for serving data to clients and for processing incoming client actions. ## Why do we need messaging among the off-chain Forum? - Different clients may connect to different Forum nodes. We want each client to be notified when other clients perform actions in the Forum. - Forum nodes already need public addresses to accept connections from clients. We can use this to enable Forum nodes to connect to each other as well. - Unless we want to rely on a third-party hosted operational database, we need messaging among Forum nodes to support the consensus protocol for a distributed operational database. ## What are the on-chain dependencies for the off-chain Forum? - Reputation: Forum network will rely on reputation tokens, awarded by on-chain validation pool, in order to secure communications in the off-chain network. - Forum Validator: Forum nodes will use a voting contract to enact reputation effects on-chain. - Network Node: Associates will need to stake reputation to register network nodes. - Funding: Network nodes will have to pay blockchain transaction fees. We can use a smart contract to receive fees for this purpose. This can function as an investment vehicle. Funders can be paid back when the DAO receives payments from other sources.
laddhoffman commented 2022-09-26 11:15:43 -05:00 (Migrated from gitlab.com)
Copy Link

Off-chain Forum, High Level Architecture

For simplicity, this diagram omits some contracts, especially various contracts related to DAO governance.

flowchart BT

subgraph Users
    associate[Associate]
    outsider[Public]
end

subgraph User Agents
    user_agent[Web Client]
end

subgraph forum_network [Off-chain Forum Network]
    node[Node]
    forum_storage[Storage]
    forum_messaging[Messaging]
end

subgraph contracts [On-chain Contracts]
    reputation[Reputation]
    validator[Validator]
    forum_contract[Forum]
    business_contract[Business]
    network_contract[Network]
    availability_contract[Availability]
end


%%node --- forum_contract
%%node --- validator
%%node --- reputation
%%node --- network_contract
node --- forum_storage
node --- forum_messaging

node --- network_contract

network_contract --- reputation
network_contract --- forum_contract

validator --- reputation
validator --- forum_contract

business_contract --- reputation
business_contract --- forum_contract
business_contract --- validator
business_contract --- availability_contract

availability_contract --- reputation

forum_contract --- reputation

associate --- user_agent
associate --- node

outsider --- user_agent

user_agent --- contracts
user_agent --- forum_network

%% user_agent --- network_contract
%% user_agent --- reputation
%% user_agent --- availability_contract
%% user_agent --- business_contract
%% user_agent --- forum_contract
# Off-chain Forum, High Level Architecture For simplicity, this diagram omits some contracts, especially various contracts related to DAO governance. ```mermaid flowchart BT subgraph Users associate[Associate] outsider[Public] end subgraph User Agents user_agent[Web Client] end subgraph forum_network [Off-chain Forum Network] node[Node] forum_storage[Storage] forum_messaging[Messaging] end subgraph contracts [On-chain Contracts] reputation[Reputation] validator[Validator] forum_contract[Forum] business_contract[Business] network_contract[Network] availability_contract[Availability] end %%node --- forum_contract %%node --- validator %%node --- reputation %%node --- network_contract node --- forum_storage node --- forum_messaging node --- network_contract network_contract --- reputation network_contract --- forum_contract validator --- reputation validator --- forum_contract business_contract --- reputation business_contract --- forum_contract business_contract --- validator business_contract --- availability_contract availability_contract --- reputation forum_contract --- reputation associate --- user_agent associate --- node outsider --- user_agent user_agent --- contracts user_agent --- forum_network %% user_agent --- network_contract %% user_agent --- reputation %% user_agent --- availability_contract %% user_agent --- business_contract %% user_agent --- forum_contract ```
laddhoffman commented 2022-10-04 20:14:16 -05:00 (Migrated from gitlab.com)
Copy Link

changed title from MVPR Architecture: CRDAO to {+[SD-5] +}MVPR Architecture: CRDAO

changed title from **MVPR Architecture: CRDAO** to **{+[SD-5] +}MVPR Architecture: CRDAO**
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
semantic-scholar-import
dev
forum-test-6
forum-network
Labels
Clear labels   
discussion

   
draft
No Label
discussion
draft
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: DGF/dao-governance-framework#5
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?