Validation Pool: Difference between revisions
mNo edit summary |
|||
Line 43: | Line 43: | ||
=== Domain-specific REP === | === Domain-specific REP === | ||
One post can be reposted with different fees for different types of REP. | One post can be reposted with different fees for different types of REP. | ||
==Code== | |||
==See Also == | |||
==Notes & References== |
Revision as of 10:59, 16 March 2023
The Validation Pool is the mechanism for minting new REP tokens and holding REP-weighted votes to determine their distribution in the DAO. A new Validation Pool is called to register consensus on every assertion made in the DAO. It is a smart contract whose function is analogous to a betting pool, in that members may register their votes with REP tokens, then, in a binding vote, those voting for the losing side have their tokens redistributed to the winners, proportionally. Most Validation Pools result in unanimous agreement and are held merely to motivate and demonstrate consensus in a decentralized organization.
Specification
Overview
An instantiation of the Validation Pool Smart Contract (VPSC) takes as initial input a new post's address in the Forum, a cash fee, and a type of REP tokens to be minted. VPSC returns newly minted REP tokens. In addition each owner of REP tokens specific to the domain of the post may encumber their tokens and vote up or down on the post. VPSC redistributes the new REP and the encumbered REP as described below.
Let denote the total number of reputation tokens in a DAO with experts for . An expert is defined as anyone who owns a REP token. Let denote the number of tokens owned by expert . So
Mint new REP
When VPSC is called, the fee is encumbered, and new REP tokens are minted of the type specified. The parameter determines the proportional number of REP minted to the fee, as set by the DAO.
Vote
VPSC then encumbers default of the newly minted tokens in the poster's name as an upvote, and encumbers of the newly minted tokens as a downvote, left unassigned to any owner until the completion of the smart contract. The fraction of the new tokens is thus given to the worker who put their evidence of work in the post. The remaining fraction of the new REP tokens is given as a reward for participating in policing.
VPSC then allows each expert to encumber any of their REP tokens (of the proper type) with an input of upvote () or downvote () or default abstention (). Once the voting period is finished, VPSC counts the votes by calculating the vote total If that means the total REP used to upvote outweighs the total REP used to downvote This means Therefore if the post is validated. If then the downvote wins and the post is invalidated. (The fact that results in validation reflects the almost arbitrary decision that ties will always favor the upvotes.)
Redistribution: binding vs. non-binding
The newly minted tokens on the losing side are distributed to the winning side proportionally. I.e., if upvotes win, each expert voter with receives of the new tokens. If downvotes win, each voter with receives of the new tokens. In that case, those tokens were taken from the poster whose post was invalidated. This proportional arithmetic ensures that someone who risks twice as many REP tokens on an assertion earns twice as much reward if they win.
A VPSC can be binding or non-binding. If an instantiation of the VPSC is binding, that means the REP tokens of all those who voted against the winning side will lose the tokens they encumbered to those who won, proportionally. E.g., if the post is validated, then all the REP used to downvote is redistributed to those who upvoted, meaning each voter with receives new tokens.
Finally, a VPSC can be -binding for any . A -binding VPSC redistributes the fraction of the losers' tokens to the winners.
Consequences
The Validation Pool can be set to binding or non-binding votes to serve the function of executive or legislative governance.
Binding votes and executive governance
Main article: Executive governance
A binding vote means the REP tokens are tightly-coupled with the voters' assertions about the post--if their assertion fails, the voter loses their tokens. For stability, this should only happen when the voter is violating the previously determined will of the DAO. Binding votes, therefore, should be used only for policing previously ratified protocols. Binding votes are only for executive governance, meaning policing, which should be automated as much as possible, so that the members' UI votes correctly every time. This means that almost always, executive governance is expensive and wasteful. There is continual communication between every member of the DAO using REP encumbered transactions in order to hold unanimous votes on every official action the DAO performs. Unfortunately, this is the necessary cost for decentralization. Since no centralized authority exists to govern the behavior of the group, everyone in the group must govern the behavior of everyone else.
The only time such executive governance policing will result in a vote which is not unanimous, is when someone is not running the most current canonical version of the UI, which will hold up-to-date standards for behavior and the correct versions of the newest approved smart contracts. Executive governance policing is required to prevent Byzantine behavior. And it needs to be funded by sharing of all the newly minted REP tokens the DAO ever generates in order to motivate maximal participation to ensure policing is decentralized. (See REP tokenomics for an analysis of the cost of policing, based on the choice of parameter . The basic idea is to choose large enough that the cost of running the hardware is sufficiently remunerated.)
Non-binding votes and legislative governance
Main article: Legislative governance
On the other hand, a non-binding vote means the REP tokens are loosely-coupled with the voters' assertions about the post--if their assertion fails, the voter will not lose their tokens. This mechanism of non-binding votes encourages authentic deliberation in the course of legislative governance. The basic idea is to encourage timely adoption of carefully considered protocol updates through a series of Validation pools, moving from loosely-coupled votes to tightly-coupled votes, through a series of -votes as is programmed to move from 0 to 1. The loosely-coupled votes are voluntary polls of proposals intended to elicit authentic opinion. The tightly-coupled votes ensure validated protocol updates are official, since binding Validation Pools force unanimity. By using a final vote which is binding, everyone who participates registers the same opinion by algorithmic force, since minority dissent is punished by loss of tokens. Consensus is assured even if it is merely tacit acceptance. It is obviously not ideal to stifle those with differing views. But it is occasionally necessary for the decentralized body to require a timely choice in order to react to the changing market.
????
Table ?? holds a summary of this thinking. Binding Non-binding Rigid Non-contentious post & tightly-coupled (E.g., work-evidence post, mandatory plebiscite) Non-contentious post & loosely-coupled (E.g., poll of consensus on established precedent) Flexible Contentious post & tightly-coupled (E.g., forcing consensus on protocol development) Contentious post & loosely-coupled (E.g., protocol development poll, advisory referendum)
Domain-specific REP
One post can be reposted with different fees for different types of REP.