Editing
Validation Pool roll up
(section)
Jump to navigation
Jump to search
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== 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 Contract|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 workflow|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 <math>p %</math> 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 contract|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 <math>p %</math> of the fees for the week to the rDAO members in the rREP salary and <math>(100-p) %</math> to the DAO members in the [[Reputation#REP%20Salary%20Mechanism|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 [[Validation Pool roll up#Tokenomics calculations|tokenomics calculations]] and [[Validation Pool roll up#Judicial governance|judicial governance]], below.)
Summary:
Please note that all contributions to DAO Governance Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
DAO Governance Wiki:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
Namespaces
Page
Discussion
English
Views
Read
Edit
Edit source
View history
More
Search
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Tools
What links here
Related changes
Special pages
Page information