From 22c62d9953a7e1f7944f2b9af1d998b0f3d67b90 Mon Sep 17 00:00:00 2001 From: Ladd Hoffman Date: Thu, 16 May 2024 20:12:30 -0500 Subject: [PATCH] spec: system design: contracts and matrix, stub --- specification/docs/requirements.md | 10 ++++++++-- specification/docs/system-design.md | 28 ++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+), 2 deletions(-) diff --git a/specification/docs/requirements.md b/specification/docs/requirements.md index b6c1050..3ac9e44 100644 --- a/specification/docs/requirements.md +++ b/specification/docs/requirements.md @@ -16,7 +16,11 @@ Validation Pools mint and award Reputation (REP). REP can be used for staking fo 1. `transfer` and `transferFrom` are disabled, so that REP may not be transferred. -#### Validation Pool +#### Bench of Experts + +The contract housing the Validation Pools can be thought of as a Bench of Experts. +These experts sit ready to receive submissions and render a decision on each. +The experts will stake their reputation on the soundness of their judgements. 1. Anyone may initiate a Validation Pool @@ -30,7 +34,9 @@ Validation Pools mint and award Reputation (REP). REP can be used for staking fo 1. A Validation Pool must include the following parameters - 1. Quorum (between 0 and 1) + 1. Quorum (Between 1/10 and 1) + + 1. Quorum must be greater than or equal to a minimum value, such as 1/10, in order to prevent validation pools from being pushed through without sufficient participation. 1. Win Ratio (between 0 and 1) diff --git a/specification/docs/system-design.md b/specification/docs/system-design.md index e69de29..d1beb43 100644 --- a/specification/docs/system-design.md +++ b/specification/docs/system-design.md @@ -0,0 +1,28 @@ +## Contracts + +In the [Requirements](./requirements.md) section, we identified the following smart contracts: + +1. Reputation +1. Bench +1. Work +1. Proposal +1. Forum +1. Rollup + +We also identified the need for a mechanism for coordinating Rollup Post validation. + +The following are reasons to submit a particular Post on-chain: + +- To conduct an on-chain Validation Pool tarageting that Post +- To enable other Posts to reference the given Post. + +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 Post on-chain representing multiple off-chain Posts. We call this a Rollup Post. + +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. + +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. + +## Matrix + +To address the need for coordination of off-chain Posts and Validation Pools, we introduce Matrix. [Matrix](matrix.org) is a messaging protocol, and it has multiple implementations. Our prototype uses Synapse as the Homeserver. Our system communicates with the Homeserver using the Client-Server protocol. +