sys design: rollup details

specification/docs/implementation-solidity.md

@@ -21,7 +21,23 @@ Each of the core contracts must first be deployed. Then the DAO contract is depl
 
 ### Bench
 
+`delegatedStakeOnValidationPool`
+
+### Forum
+
+`getPostAuthors`
+
+`propagateReputation`
+
+## Availability
+
+`DAO.stakeAvailability`
+
+`acceptAvailability`
+
+`randomWeightedSelection`
+
+
+
 ## Other
 
-- `getPostAuthors`
-- `propagateReputation`

specification/docs/system-design.md

@@ -162,7 +162,7 @@ To achieve the Forum requirements, the contract must do the following:
 | `initialNegative` | boolean |
 | `depth` | integer |
 
-Logic for **`PropagateReputation`**
+**`PropagateReputation`** Logic
 
 1. `PropagateReputation` is a recursive function.
 
@@ -180,7 +180,7 @@ Logic for **`PropagateReputation`**
     `PropagateReputation` should therefore return the amount that was unable to be propagated. We refer to this as a "refund". Subtracting this refund amount from the attempted amount gives the actual amount propagated.
 
 
-### Proposal
+### Proposals
 
 To achieve the Proposals requirements, the contract must do the following:
 
@@ -216,8 +216,26 @@ To achieve the requirements, the Availability contract must do the following:
 
 1. Implement a method to accept Worker availability stakes
 
+    1. If a Worker submits multiple availability stakes, they may be combined into a single availability stake.
+
 1. Implement a method to select a Worker by random weighted selection, weighted by the amount each Worker staked.
 
+**`StakeAvailability`** Parameters
+
+| Name | Type |
+| --- | --- |
+| `amount` | integer |
+| `duration` | integer |
+
+**`Availability Stake`** Properties
+
+| Name | Type |
+| --- | --- |
+| `worker` | wallet address |
+| `amount` | integer |
+| `endTime` | integer |
+| `assigned` | boolean |
+
 ### Work
 
 To achieve the Work Smart Contract requirements, a work contract must do the following:
@@ -230,6 +248,8 @@ To achieve the Work Smart Contract requirements, a work contract must do the fol
 
 1. Implement a method for a Customer to request work
 
+    1. This should be a payable method
+
 1. Implement a method for a Worker to submit Work Evidence (WEV)
 
 1. Implement a method for a Customer to submit work approval/disapproval
@@ -240,9 +260,9 @@ To achieve the Work Smart Contract requirements, a work contract must do the fol
 
 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.
+With this Rollup Post, we have the opportunity to attribute credit to multiple authors, with a weight assigned to each author. 
 
-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.
+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.
 
 To achieve the Rollup requirements, the contract must do the following:
 
@@ -252,6 +272,8 @@ To achieve the Rollup requirements, the contract must do the following:
 
 1. Implement a method to add an item to the queue of items to be batched
 
+    1. This should be a payable method
+
 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
@@ -260,6 +282,54 @@ To achieve the Rollup requirements, the contract must do the following:
 
     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.
 
+**`AddItem`** Parameters
+
+| Name | Type |
+| --- | --- |
+| `author` | wallet address |
+| `postId` | string |
+| `stakeAmount` | integer |
+
+**`Batch Item`** Properties
+
+| Name | Type |
+| --- | --- |
+| `sender` | contract address |
+| `worker` | wallet address |
+| `postId` | string |
+| `stakeAmount` | integer |
+| `fee` | integer |
+
+**`SubmitBatch`** Parameters
+
+| Name | Type |
+| --- | --- |
+| `batchPostId` | string |
+| `batchItems` | Array<string> |
+| `poolDuration` | integer |
+
+**`SubmitBatch`** Logic
+
+1. A batch may only be submitted by the currently assigned Batch Worker, unless there is no currently assigned Batch Worker.
+
+1. `batchItems` is an array of Post IDs that are included in the batch.
+
+    1. Submitted batch length must not exceed the length of the current batch queue.
+
+    1. Each Post ID in the submitted batch must match, in order, the Post IDs in the batch queue, up to the length of the submitted batch.
+
+1. A Validation Pool should be initiated targeting the `BatchPostId`.
+
+    1. The fee included when initiating this VP should be the sum of the fees for each item included in the submitted batch.
+
+1. For each included item, `stakeAmount` should be staked in favor of the VP on behalf of the Worker that submitted the item.
+
+1. The availability stake of the current batch worker should be staked in favor of the VP.
+
+1. The submitted items should be removed from the batch queue. 
+
+1. A new batch worker should be assigned.
+
 ## Off-chain Operations
 
 As outlined in the Rollup section above, we need to define processes for handling off-chain Posts and Validation Pools. Posts are represented by a unique identifier on-chain, but the Post content is 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, for supporting web clients in reading and writing posts. We use Matrix as the off-chain forum database. Each Forum API instance will read the history and receive new posts using the Matrix client-server protocol.