dgf-prototype/specification/docs/system-design.md

196 lines
7.2 KiB
Markdown
Raw Normal View History

2024-05-19 17:05:13 -05:00
# System Design
2024-05-19 17:53:57 -05:00
In the [Requirements](./requirements.md) section, we identified the need for the following smart contracts: Reputation, Bench, Forum, Work, Proposal, and Rollup.
2024-05-19 17:05:13 -05:00
2024-05-19 17:57:36 -05:00
We also identified the need for a mechanism for coordinating Rollup Post validation. To address this need, we introduce [Matrix](https://matrix.org), a federated messaging protocol. Our application uses the Client-Server protocol to communicate with a Matrix Homeserver.
2024-05-19 17:05:13 -05:00
## Contracts
The following is a dependency graph, where the arrows represent one contract calling another.
```mermaid
flowchart BT
subgraph Core Contracts
Reputation
Bench
Forum
end
subgraph Business Logic
Work
Proposal
Rollup
end
Bench --> Reputation
2024-05-19 17:52:46 -05:00
Proposal --> Bench
Proposal --> Reputation
2024-05-19 17:05:13 -05:00
Work --> Reputation
Work --> Bench
2024-05-19 17:56:10 -05:00
Work --> Rollup
2024-05-19 17:52:46 -05:00
Work --> Proposal
2024-05-19 17:05:13 -05:00
Forum --> Reputation
Bench --> Forum
Rollup --> Bench
```
Reputation, Forum, and Bench can be considered core contracts. Together they provide the necessary primitives for a DAO to carry out its business.
Work, Proposal, and Rollup can be considered business logic. They allow the DAO to support arbitrarily complex use cases, according to its needs.
### Reputation
We can achieve the requirements of the Reputation contract as follows:
1. Reputation may be implemented as an ERC20 token contract.
1. `transfer` and `transferFrom` methods must be disabled, so that REP may not be transferred.
1. Reputation internal methods (`mint`, `burn`, `update`) may be called only by the Bench and Forum contracts.
### Bench
To achieve the Bench requirements, the contract must do the following:
2024-05-19 17:52:46 -05:00
1. Define a minimum quorum
1. Define a minimum and maximum VP duration
2024-05-19 17:05:13 -05:00
1. Keep a record of Validation Pools
1. Implement a method for initiating a Validation Pool (VP)
2024-05-19 17:52:46 -05:00
1. The caller should be able to provide an optional callback to be executed when the VP is concluded
2024-05-19 17:05:13 -05:00
1. Implement a method for evaluating the outcome of a Validation Pool
2024-05-19 17:52:46 -05:00
1. If provided, the callback should be executed, and should be passed the results of the VP
2024-05-19 17:05:13 -05:00
2024-05-19 17:52:46 -05:00
### Forum
2024-05-19 17:05:13 -05:00
2024-05-19 17:52:46 -05:00
To achieve the Forum requirements, the contract must do the following:
1. Keep a record of Posts, indexed by Post ID
1. Implement a method to add a Post
1. Implement a recursive method to distribute Reputation to a Post's references and authors.
1. This method must be called only by the Bench, when a Validation Pool is accepted.
2024-05-19 17:05:13 -05:00
### Proposal
2024-05-19 17:52:46 -05:00
To achieve the Proposals requirements, the contract must do the following:
1. Define an attestation threshold
1. Keep a record of Proposals
1. Implement a method to initiate a Proposal
1. The caller should be able to provide an optional callback to be executed when and if the Proposal is accepted
1. Implement a method for a DAO member to attest to a Proposal
1. Implement a method to evaluate the attestation for a given Proposal
1. If the attestation threshold is met, begin the referendum process
1. Implement the referendum process
1. Initiate the VP for the current stage referendum
1. Provide a callback to be executed when each referendum VP concludes, that advances the Proposal through the referenda stages according to the requirements.
1. If the Proposal passes all referenda stages, and a callback was provided, the callback should be executed.
### Availability
For convenience, we can define an Availability contract, as a base contract that other contracts may extend. Work contracts as well as the Rollup contract need to use this Availability mechanism.
To achieve the requirements, the Availability contract must do the following:
1. Keep a record of Worker availability stakes
1. Implement a method to accept Worker availability stakes
1. Implement a method to select a Worker by random weighted selection, weighted by the amount each Worker staked.
### Work
To achieve the Work Smart Contract requirements, a work contract must do the following:
1. Inherit from the Availability contract
1. Define a price for the work
1. Optionally, implement a method to initate a Proposal to change the price
1. Implement a method for a Customer to request work
1. Implement a method for a Worker to submit Work Evidence (WEV)
1. Implement a method for a Customer to submit work approval/disapproval
1. Once approval/disapproval is submitted, either initiate a Validation Pool tarageting the WEV, or submit the fee and worker's REP stakes to the Rollup contract instead (explained below).
2024-05-19 17:05:13 -05:00
### Rollup
Rather than submit every Post on-chain and conduct every Validation Pool on-chain, it is more efficient to keep a collection of Posts off-chain, and add a single Rollup Post on-chain representing multiple off-chain Posts.
With this Rollup Post, we have the opportunity to attribute credit to multiple authors, with a weight assigned to each author. We can express this weight as parts per million (PPM), for a balance between numerical precision, and ease of visual recognition.
2024-05-19 17:53:57 -05:00
The Rollup Post can weight authorship in accordance with the off-chain Validation Pools that have taken place. The off-chain system can fully model the Forum and Bench outlined in the [Requirements](./requirements.md) section. For demonstration purposes, our prototype makes some simplifying assumptions. Work Evidence Posts (WEV) are assumed to contain no references to prior Posts. In reality, we want WEV to be able to reference prior Posts, such as those representing policies of the DAO, prior work by other DAO members, prior art outside the DAO, and so on. So, a proper implementation of this system should account for these references, just as the Forum contract must.
2024-05-19 17:05:13 -05:00
2024-05-19 17:52:46 -05:00
To achieve the Rollup requirements, the contract must do the following:
1. Inherit from the Availability contract
1. Keep a queue of items to be batched
1. Implement a method to add an item to the queue of items to be batched
1. Implement a method for the current batch worker to initiate a Validation Pool targeting a Rollup Post that represents items from the batch queue.
1. Items must be submitted in order without skipping any items
1. Implement a method to select a new batch worker
1. If this method is called to replace a batch worker who has failed to submit the next batch, a Validation Pool should be initiated and the batch worker's stakes submitted in favor of the VP. The DAO members may then stake against this VP, punishing the worker who failed to submit the batch.
2024-05-20 15:06:24 -05:00
## Off-chain Operations
2024-05-19 17:05:13 -05:00
2024-05-20 15:06:24 -05:00
As outlined in the Rollup section above, we need to define processes for handling off-chain Posts and Validation Pools. On-chain, Posts are represented by a unique identifier, but the Post content is always stored off-chain. So, every on-chain Post must have a corresponding off-chain Post. These off-chain posts should be visible to the public. To achieve this, we introduce a Forum API, that supports writing and reading off-chain Posts.
2024-05-19 17:05:13 -05:00
2024-05-20 15:06:24 -05:00
### Forum API
2024-05-19 17:05:13 -05:00
2024-05-20 15:06:24 -05:00
#### Write
Parameters
| Name | Type | Description |
| --- | --- | --- |
| sender | Wallet address | |
| authors | Array of tuples: Wallet address, author weight |
| content | String |
| cit
#### Read
## Automated Staking
2024-05-20 08:54:38 -05:00
2024-05-20 15:06:24 -05:00
### Validation Pool
2024-05-20 08:54:38 -05:00
2024-05-20 15:06:24 -05:00
### Rollup
2024-05-20 08:54:38 -05:00
## User Interface
### Web App
### Widget
2024-05-19 17:05:13 -05:00
## Other
- Register Matrix Identity
- Imprt from Semantic Scholar
- Import from Matrix
- Bot Commands