Editing Validation Pool roll up (section)

== Other features ==
Several native DGF functions 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.

=== Judicial governance ===
For security, to disincentivize Byzantine behavior, perpetual review should be possible for each roll up.

DGF naturally includes the [[Executive governance|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 [[Transcendent values#Game theory argument|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 governance proposal|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.

=== 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 [[Reputation tokenomics|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.