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. To maintain robust decentralization, every member of the DAO should be permitted equal opportunity to participate in policing by voting with their REP tokens.
But each time a member votes with a REP token becomes a separate transaction. Also, properly participating members should have their REP holdings augmented with newly minted tokens (to solve the "nothing at stake problem"), 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.
Fortunately, DGF is designed for the express purpose of governing off-chain work.
Basic process
An individual member of the roll-up DAO (rDAO) is randomly chosen to be the rWorker leader for a specified period (e.g., 1 week) and host a temporary standardized website and database that runs off-chain Validation Pools (VPs) to resolve all Work Smart Contracts (WSCs) that occur during that period. A randomly chosen subgroup of rDAO members (e.g., a team of 10) are also selected to observe the Validation Pools for the week and police the leader. At the end of the week the rWorker leader 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) and publishes the result with proof to the Forum. Then the bundled $ fees and REP are sent to a standard Validation Pool for the rest of the DAO to validate.
More complicated roll-up logic than given in the previous paragraph 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, making the DGF roll up process a hybrid. The point of this roll up process is that DGF tools give us 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.
A DGF roll up consists of a current roll up Work Smart Contract (rWSC) and a canonical roll up client.
The canonical roll up client specifies how to host the off chain work. The client will spawn a website for customers to engage the DAO using the WSC and will temporarily host the database needed to run the week's Validation Pools.
The rWSC handles the $ fees for the week, specifies a percentage of the rolled up WSC fees given for performing roll-up work, and performs the executive governance process detailed in the following list:
- rWSC randomly selects a worker from the rDAO from amongst its available members, i.e., those who have encumbered rREP tokens in roll-up Availability Smart Contracts (rASCs).
- Selected rWorker completes rWSC job offline for 1 week.
- rWorker inputs aggregated information to rWSC:
- Each WSC instantiation and the results of their VPs
- All WSC instantiations send their customer $ fees to the rWSC. (So, the rWorker doesn't have power over these fees. After the rWSC concludes, it gives of the fees for the week to the rDAO members in the rREP salary and to the DAO members in the normal REP salary.)
- 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.)
- rWSC ends and triggers the next rWSC. (Go to 1.)
In summary, the randomly selected rWorker uses their rREP to get control of the REP governance of the validation process for 1 week. The rWorkers are not given control of the $ fees. However, rWorkers can censor transactions (votes). Therefore, if the rWorker is not properly incentivized and policed, then they are motivated to violate the rules and take the REP generated by policing for themselves. The way to incentivize the rWorker is to promise more $ remuneration in the future for faithfully following protocol than they can make in the short run from Byzantine actions, while also policing properly. (See the respective sections on tokenomics calculations and judicial governance, below.)
Other features
Several options arise to make the optimistic roll up process more secure and better incentivized.
Subgroup policing
One way to automate the rVP policing process involves a team of random members monitoring 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 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 if their checks fail. Whether all 10 team members sign off determines how the rest of the entire rDAO should vote in the rVP.
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. One 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. (Censorship is a well-known problem in decentralized computing, especially in block production consensus mechanism research. An example of censorship is that the team might ignore messages from other members who were voting in the VP policing instantiations. That would make the team's REP larger than it should be if they faithfully ran the roll up.) Therefore, the amount of fees that are handled by a team should not give policing REP from the VP instantiations for their week which have greater present value than the expected rREP salaries of an rWorker. This tokenomics 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.
Judicial Governance
For security, to disincentivize Byzantine behavior, perpetual review should be possible for each roll up.
DGF naturally includes the executive review of each roll up via the rValidation Pool for each rWSC. rValidation Pools police the rWorkers automatically before they receive their new rREP for successful work, and also threaten the slashing of rWorkers' availability stakes rREP if they do not follow protocol.
To greater incentivize faithful execution of roll ups, rWorkers' rREP can be tied together, since there is a record of the history of all newly minted rREP in the Validation Pool which is connected to the previous rREP that the rWorker encumbered in the rASC that was selected by the rWSC. Therefore the entire history of all the rWorker's rREP is subject to automatic slashing if they exhibit Byzantine behavior that violates the current protocols for roll-up work.
However, there will still inevitably be a perpetual arms race for finding ways to game the system. Regardless of how carefully the protocols are written, there is always a way to profit at the expense of the larger group while following the letter of the law (see game theory argument). So it is possible that the DAO would wish to slash rREP even if the Validation Pool didn't automatically catch such second-order Byzantine behavior.
Therefore, it is essential that all rREP be subject to future judicial review if it is ever suspected that an rWorker has violated the values of the group and harmed the DAO. This type of judicial policing is enabled by implementing DGF's judicial governance protocols. In particular, the DAO should implement standardized judicial proposals to slash Byzantine members' rREP, and meaningfully motivate such proposals by paying for them with a percentage of the rREP that is slashed.
Code
Pseudocode
An instantiation of rDAO flow appropriate for programming on Ethereum is described as follows:
1. Accept three initial inputs : #Usually the inputs come from the Work Smart Contract
Downloads
See Also
- Chit Fund DAO
- Danksharding in Ethereum