Validation Pool roll up

A Validation Pool roll up is an example of a roll up in a DAO built with DGF. Multiple instantiations of Validation Pools are conducted off chain, then the aggregated result is put on chain with a single transaction.

Background

On-chain voting is inefficient and prohibitively expensive. However, voting is necessary for decentralized governance. And to maintain robust decentralization, every member of the DAO should be permitted equal opportunity to participate in voting with their REP tokens, and every member should be permitted to police the entire process. By using their REP tokens, every member's vote becomes a separate transaction, and every participating member should have their REP holdings augmented with newly minted tokens, which necessitates yet another transaction.

Instead of doing all of these operations separately and on chain, it is more efficient to handle the operations off chain, then roll up the result in a single transaction in a single block. Even better, efficiency is improved if we bundle together a sequence of several separate instantiations of Validation Pools.

Basic process

An individual member of the roll up DAO (rDAO) is randomly chosen to be the rWorker for the week and host a temporary standardized website and database that runs off-chain Validation Pools to resolve all WSCs for that week. A randomly chosen subgroup of 100 rDAO members are selected to participate in the Validation Pools for the week and police WSCs. At the end of the week the rWorker rolls up the conclusions of all Validation Pools (i.e., the changes in REP holdings and $ fee salaries to all the accounts of all members of the DAO) publishes the result and proof that the result is correct to the Forum. Then the bundled $ fees and REP are sent to a standard Validation Pool for the rest of the DAO to validate.

Clearly, more complicated roll-up logic can be implemented to increase the efficiency and security of the process. As detailed here, this roll up logic gives an example of an "optimistic roll up" as opposed to a zk-roll up. Clearly, however, zk-roll up logic can be naturally included in this process, to make it a hybrid. The point of DGF roll up process is that it gives the proper incentive structure and policing mechanism to make optimistic roll ups pragmatic and secure.

Details

Here we give an abstracted version of a specific instantiation of a Validation Pool roll up.

Roll up executive governance

Following basic DGF work flow, a random rWorker performs off-chain Validation Pools for 1 week, then submits the results for validation by the rDAO.

The roll up Work Smart Contract (rWSC) specifies proper roll-up work. I.e., how to run all Validation Pools for 1 week. rWSC specifies a percentage $p\%$ of the rolled up WSC fees are given for roll up work.

1. rWSC randomly selects a worker from the rDAO from amongst the available members who have encumbered rREP tokens in roll up availability smart contracts (rASCs).
2. Selected rWorker completes rWSC job offline for 1 week.
3. rWorker inputs aggregated information to rWSC.
   • Each WSC instantiation
   • All WSC instantiations send their customer $ fees to the rWSC automatically. (rWorker doesn't have power over these fees. After the rWSC concludes, it gives $p\%$ of the fees for the week to the rDAO members in the rREP salary, and $(100-p)\%$ to the DAO members in the REP salary after the rWSC concludes.)
4. rWSC publishes evidence of completed roll-up job to a post in the Forum, opens an instantiation of the main on-chain rValidation Pool. Entire DAO validates the roll up.
   • rVP mints new rREP in proportion to the collected $ fees for the week.
   • rVP publishes the result & distributes rREP tokens & REP salary (At this stage, the rWorker either receives new rREP or the rREP encumbered in the rASC is slashed.)
5. rWSC ends and triggers the next rWSC. (Go to 1.)

In summary, the randomly selected rWorker uses their rREP to get control of the $ fees and governance of the validation process for 1 week. If the rWorker is not properly incentivized to do the job faithfully, then they are motivated to violate the rules and take the $ fees for themselves. The way to incentivize the rWorker is to promise more $ remuneration in the future and/or to police them properly.

Pseudocode

An instantiation of rDAO flow on Ethereum is described as follows:

1. Accept three initial inputs :                        #Usually the inputs come from the Work Smart Contract

Complications

Several options arise to make the optimistic roll up process more secure and better incentivized.

Subgroup policing

A more sophisticated roll up process will involve a team of random members performing the rollup. For example, instead of a single member being selected by the rWSC, a team of 10 members are randomly selected. All 10 team members are given signing power in the rWSC. All 10 must sign off before the $ fees from the week's WSCs are disbursed.

All 10 team members run the roll up client in parallel. One of the 10 is selected as leader. The others check that the leader's roll up is the same as theirs, and don't sign off on the $ fee transactions if the check fails.

Tokenomics calculations

To guarantee the incentives are correct, the rollup team should not be able to collude to gain more REP salary fees by violating the process than they could by participating faithfully in the long run. The way a team could violate the process is to give themselves more of the REP than they deserve. For instance, there is no way to prevent a colluding team from censoring other DAO participants. (This is a well-known problem in decentralized computing. The team could pretend they didn't get messages from other members who were voting in the VP policing instantiations. That would make the team's REP larger than it should be.) Therefore, the amount of fees that are handled by a team should not give policing REP from the VP instantiations for their week which are greater than the present value of the expected rREP salaries of an rWorker. This calculation is affected by the measured safety the zk proofs guarantee, meaning the likelihood of the colluding team to be slashed instead of rewarded for Byzantine behavior.