Rollup requirements
Gitea Actions Demo / Explore-Gitea-Actions (push) Failing after 34s
Details
Gitea Actions Demo / Explore-Gitea-Actions (push) Failing after 34s
Details
This commit is contained in:
parent
40da0a0a2c
commit
b11f777362
|
@ -150,3 +150,46 @@ This Forum reference mechanism enables executing any conceivable change in the R
|
|||
|
||||
## Rollup
|
||||
|
||||
As described above, in order for REP and fees to be distributed to DAO members, an on-chain Validation Pool must be executed. However, network gas fees must be payed every time a contract is called. Therefore a DAO may wish to batch multiple Posts and the Validation Pools targeting those posts into one consolidated Rollup Post and a single Validation Pool targeting that Rollup Post. To accomplish this, we introduce a Rollup contract.
|
||||
|
||||
The Rollup contract can be thought of as a specialized form of Work Contract (WSC), as it uses the same Availability stakes mechanism to select a batch worker.
|
||||
|
||||
1. When the Rollup contract is deployed, a Batch Interval must be specified.
|
||||
|
||||
1. A Work Contract may call the Rollup contract to add an item to the batch queue.
|
||||
|
||||
1. The fee that would have gone toward the VP, goes to the Rollup contract instead.
|
||||
|
||||
1. The Worker availability stakes that would have gone toward the VP, go to the Rollup contract instead.
|
||||
|
||||
1. A Worker may stake REP to register their availability to be the next batch worker.
|
||||
|
||||
1. Once the Batch Interval has elapsed, the current batch worker must add a Rollup Post to the Forum and call the Rollup contract to initiate a Validation Pool targeting the Rollup Post.
|
||||
|
||||
1. Only the current batch worker may submit the next Rollup batch.
|
||||
|
||||
1. If there is no current batch worker assigned, then anyone may submit the next Rollup batch.
|
||||
|
||||
1. When the batch is submitted,
|
||||
|
||||
1. Rollup contract initiates a Validation Pool targeting the Rollup Post.
|
||||
|
||||
1. The fees that were included with each batch go toward the Rollup VP.
|
||||
|
||||
1. The REP stakes that were included with each batch go toward the Rollup VP.
|
||||
|
||||
1. The next batch worker is selected by random weighted selection from among the Batch worker availability stakes.
|
||||
|
||||
1. If there are no Batch worker availability stakes, the transaction reverts, so the VP is not initiated.
|
||||
|
||||
1. If the current batch worker fails to submit the next Rollup batch before the Batch Interval plus a grace period elapses,
|
||||
|
||||
1. A Validation Pool should be initiated with no fee
|
||||
|
||||
1. The batch worker's availability stake should be staked in favor of the VP
|
||||
|
||||
1. A new batch worker must be selected
|
||||
|
||||
1. The DAO members should stake against the VP, in order to punish the batch worker for failing to complete their work
|
||||
|
||||
In this requirements section, we omit any details of the mechanisms for implementing the necessary off-chain validation that leads to the production and verification of the Rollup Post. We will provide those details in the [System Design](./system-design.md) section.
|
Loading…
Reference in New Issue