147 lines
4.2 KiB
Markdown
147 lines
4.2 KiB
Markdown
|
A DAO is a group of cooperating entities.
|
|||
|
|
|||
|
If we're running our own network, it probably makes sense to consider nodes as the participants.
|
|||
|
|
|||
|
If we're running as smart contracts, it probably makes sense to consider individual addresses as the participants.
|
|||
|
|
|||
|
These schemes overlap, since both involve asymmetric keys.
|
|||
|
|
|||
|
Each node must validate the work of the other nodes
|
|||
|
|
|||
|
Our protocol will be a peer protocol, and will rely on signatures.
|
|||
|
|
|||
|
Therefore we arrive at a requirement for nodes: they must be physically secured so that private keys are protected.
|
|||
|
|
|||
|
We also arrive at a requirement for our network protocol: It must be possible to sign messages and verify message signatures against known public keys.
|
|||
|
|
|||
|
The network protocol MAY support asking peers about other peers / telling other peers about peers.
|
|||
|
|
|||
|
IF we support this IT SHALL BE linked with each node's reputation.
|
|||
|
|
|||
|
CAN WE SAY that each node MUST maintain A VIEW of THE ENTIRE / (THE CURRENT) / (ALL / CURRENT) HASHES / MERKLE TREE / -- World state, History
|
|||
|
|
|||
|
CAN WE GET AWAY WITH ONLY SAYING that each node maintains its own view.
|
|||
|
|
|||
|
WHAT is our protocol for evaluating the perspectives offered by peers?
|
|||
|
|
|||
|
- If one node perceives consensus among many others, that may sway their opinion.
|
|||
|
|
|||
|
- There may be opportunity during "informal voting" / non-binding validation pools (low tokenLossRatio) to gather this sort of information.
|
|||
|
|
|||
|
- If there is exact agreement, we have a very efficient case.
|
|||
|
|
|||
|
- If there is the HOPE of exact agreement, mistakes and attacks can be costly
|
|||
|
|
|||
|
- If there is an EXPECTATION of exact agreement, there must be externalities supporting that agreement, i.e. a common protocol and governance of that protocol.
|
|||
|
|
|||
|
---
|
|||
|
|
|||
|
# Internal operations
|
|||
|
|
|||
|
## Expert starts new DAO
|
|||
|
|
|||
|
```mermaid
|
|||
|
graph
|
|||
|
|
|||
|
subgraph EOA
|
|||
|
expert(Expert)
|
|||
|
end
|
|||
|
|
|||
|
subgraph Contracts
|
|||
|
forum(Forum)
|
|||
|
pool(Pool)
|
|||
|
end
|
|||
|
|
|||
|
expert -- Post --> forum
|
|||
|
expert -- Fee $ --> pool
|
|||
|
|
|||
|
```
|
|||
|
|
|||
|
## Expert joins existing DAO
|
|||
|
|
|||
|
```mermaid
|
|||
|
graph
|
|||
|
|
|||
|
subgraph EOA
|
|||
|
expert(Expert)
|
|||
|
peers(Peers)
|
|||
|
end
|
|||
|
|
|||
|
subgraph Contracts
|
|||
|
forum(Forum)
|
|||
|
pool(Pool)
|
|||
|
end
|
|||
|
|
|||
|
expert -- 1. Post --> forum
|
|||
|
expert -- 2. Fee $ --> pool
|
|||
|
peers -- 3. Stake ℝ<br />to approve --> pool
|
|||
|
```
|
|||
|
|
|||
|
## Expert submits governance post
|
|||
|
|
|||
|
A governance post can be considered one that is respected in some way by the operations of the [Client/UI](./client-or-ui.md).
|
|||
|
|
|||
|
This is a broad class of posts.
|
|||
|
|
|||
|
Each type of governance post can be individually (or by category?) handled by the business contract for a given DAO.
|
|||
|
|
|||
|
```mermaid
|
|||
|
graph
|
|||
|
|
|||
|
subgraph EOA
|
|||
|
expert(Expert)
|
|||
|
peers(Peers)
|
|||
|
end
|
|||
|
|
|||
|
subgraph Contracts
|
|||
|
forum(Forum)
|
|||
|
pool(Pool)
|
|||
|
business(Business)
|
|||
|
end
|
|||
|
|
|||
|
expert -- 1. Stake ℝ on<br />governance post --> business
|
|||
|
business -- 2. Post --> forum
|
|||
|
business -- 2. Fee $ from<br />internal fund? --> pool
|
|||
|
peers -- 3. Stake ℝ<br />to approve --> pool
|
|||
|
pool -- 4. Validate --> forum
|
|||
|
```
|
|||
|
|
|||
|
Forum usage is open-ended.
|
|||
|
DAO protocol consists of core contracts + client behaviors.
|
|||
|
Core contracts provide resilience to attacks, since reputation minting is financially backed by future income
|
|||
|
|
|||
|
Question: What does the DAO do with funds it receives?
|
|||
|
Awswer: Distributes the funds to members immediately upon resolution of the reputation effects of a funded validation pool.
|
|||
|
|
|||
|
---
|
|||
|
|
|||
|
Before we delve into example use cases, we need to talk about the [Client/UI](./client-or-ui.md), and make sure we have
|
|||
|
a sound understanding of how client/ui behaviors interact with the core of the system.
|
|||
|
|
|||
|
---
|
|||
|
|
|||
|
The forum, pool, business, and availability contracts all work together to express a single DAO.
|
|||
|
|
|||
|
Each post in the forum can be its own new DAO
|
|||
|
|
|||
|
What it would take for that to happen:
|
|||
|
|
|||
|
The seed of the new DAO becomes the tokens minted by that post DAO when it receives fees.
|
|||
|
|
|||
|
When will it receive fees? When submitted to its business contract interface.
|
|||
|
|
|||
|
What happens then? Work is assigned via availability stakes.
|
|||
|
|
|||
|
Meaning that someone has staked reputation.
|
|||
|
|
|||
|
Meaning that they had previously been awarded reputation.
|
|||
|
|
|||
|
The business contract, or the DAO, or the seed post, must be able to accept an initial fee
|
|||
|
to mint the reputation of the first expert.
|
|||
|
|
|||
|
Then, that expert can stake their reputation on availability to perform the work expressed by the post and its associated business contract.
|
|||
|
|
|||
|
These operations can be consolidated.
|
|||
|
|
|||
|
When submitting a post to the forum, you may include an optional fee
|