Token-Managed Registries 1.0
The idea of token-managed registry (TCR) originated in the blockchain community at least a year ago. At least, this article was published by the author in September 2017. And recently I was at the DappCon 2018 conference in Berlin and saw a great interest in this topic, as well as some early TCR-based sketches. Therefore, I assume that the peak of interest is still ahead.
TCR contracts are extremely interesting to me because they are an example of the simplest closed loop system that is managed decentralized and based on economic incentives. If we fantasize a little, it becomes clear that on the basis of this idea, much can be decentralized, perhaps even everything in our social and economic life. And this is not just a hallucination of crazy cryptans, but a quite well-formulated protocol. Read more under the cat.
Token-driven registries (token-curated registries, TCR) are cryptosystems that are increasingly used for various tasks. In this article we will present a more formal look at token-driven registries, but without mathematics.
Version 1.0 is included in the header because the TCR and incentive system described below will certainly be improved. We hope this document will be a starting point for discussions on how to improve the TCR. Many of these registries deployed today are similar, but different mechanics are used. We believe in the “right” way to create registers managed by tokens, and that it is possible to completely re-use the established implementation.
Application of token-driven registries
The output of a TCR is a list. People have a craving for them, and we see lists everywhere: shopping, “good” universities, the most wanted criminals. Some lists can be classified as white or black. In any case, the contents of the lists satisfy some criteria (goods to be bought; universities, whose graduates pay an average of 10 years of tuition fees for their studies; people for whom the FBI has awarded more than $ 100,000 for information).
Useful lists someone forms. The shopping list is usually created by one person. And the commission is probably responsible for the list of the best universities. If anyone can fill up such a list, then soon we will get a useless list of all universities, because any rector will want his institution to be mentioned there.
In TCR, for assigning management rights (curation rights), internal tokens are used in proportion to their conditional weight among subjects - holders of tokens. If there are companies that want to get on the list, then there will be a market where the material interests of rational holders of tokens will lead to the creation of a quality list. TCRs are lists with decentralized management, they financially stimulate holders of tokens to form weighted list contents.
User points of view
We distinguish three types of TCR users: consumers, candidates, token holders. Each type has its own interests, motives and ways of interacting with the registry. Consumers are looking for quality listings. Candidates tend to get there. Token holders want to increase the value of their tokens.
Consumers need quality information. If a student chooses a higher education institution on the basis of a list of institutions whose graduates pay an average of 10 years for student tuition, he will be very disappointed to find that the institution is mistakenly assigned to this category.
Candidates want to get the attention of consumers. An institution of higher education - a list participant (listee) admitted to the registry is likely to receive more applications for admission than if he were not on the list. Thanks to this, he can even increase tuition fees.
Token holders want to maintain a high demand for tokens, as this increases their value. Otherwise, the holders will not be interested in the quality content of the lists they manage. In the example of higher education institutions, holders should not be either a registry consumer or candidates for inclusion in it. To ensure that the demand for tokens does not fall, holders need to maintain high quality lists. If the registry is of high quality, candidates will want to get into it, and consumers will become familiar with it.
Holders of tokens, masterfully managing the list, can make a profit. Its size depends on the quality of management and the growing interest of consumers and candidates.
TCR incentive system
Token holders are a crypto-economic game engine that regulates TCR. For the registry to work, candidates must make deposits in the internal tokens of the registry, and then their applications for inclusion in the list will be considered. If the candidate is “good,” he is listed, his deposit is saved. Having decided to leave the list, the participant can withdraw his deposit. If the candidate is “bad”, the holders dispute his application, and after it is rejected, the deposit will be confiscated and divided as a reward among the holders of the tokens who participated in the dispute. Candidates will not apply to the registry if they do not meet its requirements: this will lead to financial losses. A university that does not offer anything worthwhile and requires $ 50,000 a year is unlikely to be accepted into the register of universities whose graduates pay off their tuition fees for an average of 10 years, so do not try. Token holders can increase their savings thanks to such a candidate. Most likely, his application will be challenged, but there is a non-zero probability that the application will be accepted.
Token holders have a tactical incentive to reject each candidate in order to increase their savings. But this is stupid, because the strategic task is to increase the cost of savings. An empty list is not needed by consumers, so candidates will not seek into it. The fundamental demand for an internal registry token depends on the candidates. Acting tactically, and not strategically, tokens holders will suffer serious financial losses. It is in their interest to achieve the strategic goal and create a quality list.
The section can be used as a reference, since in the future we will repeatedly mention the parameters listed here. We will call them snapshots of the parameters and the current mandatory (current canonical) parameters. The snapshot captures the values of the current required parameters at some point in time, they “freeze” in the snapshot and do not change, even if the current required parameters have changed. Unless otherwise specified, the parameter mentioned in the text is the current required parameter.
So many tokens the candidate must make as a deposit for accepting the list and being in it.
During this time, the inclusion of a candidate in the list can be challenged. Measured in blocks or eras. If there was no dispute, the candidate is listed.
During this time, tokens holders can vote for challenging. Measured in blocks or eras.
During this time, tokens holders may announce votes for a specific challenge. Measured in blocks or eras.
The share of confiscated deposit, which is awarded to the winner as a special permission (special dispensation), which compensates for financial risks.
The published share of the total number of tokens required for the contested candidate to be on the list / the contested participant remains on the list.
VOTE_QUORUMdoes not count tokens that did not vote, and unpublicized tokens are considered non-voting. For example, it
VOTE_QUORUM 50means that all disputes are resolved by a simple majority.
Position - an element from a single set of elements listed in the list that are contained in the TCR. In the example of universities, the position can be a simple string value that identifies the university by its well-known name, for example, Foo University. When choosing a position form, remember that it will authenticate the real object. In the case of universities, it is enough to take their names, since the falsification of the physical and social organization listed in the list of universities for the sake of consumer fraud will require too serious efforts (fake campuses, personnel, certificates, etc.).
Authentication tools, as far as possible, leave it to the discretion of users. Say, domain name registry users can authenticate their domain connections using an HTTPS certificate, a web-of-trust network or hashed secret values that are stored in the list metadata and are provided as confirmation from an oracle. It is important that list participants and de facto consumers accept at least one authentication device supported by both parties, otherwise the registry will be useless.
Filing an application
When a candidate for inclusion on the TCR list submits an application, he must make a deposit in the internal tokens of the registry. The minimum size -
MIN_DEPOSITso many tokens will be exposed as a deposit when challenging the application. The application will be reviewed (resolved) later
APPLY_STAGE_LEN. If during this time no one has challenged the application, the candidate becomes a member of the list. Otherwise, the status of the candidate is determined by the results of the contest.
The application contains a snapshot of the current required parameters, and all actions with the application refer to its parameters recorded in the image.
Challenging the application
Contesting is initiated with reference to either candidates who are awaiting consideration of the application, or to participants in the list. Only one active challenge to each candidate or participant is allowed. The challenger initiates a deposit in the amount
MIN_DEPOSITagainst the position of the list or application whose deposit exceeds
MIN_DEPOSITor is equal to it. (
MIN_DEPOSITWe will talk about challenging positions with a deposit less in the section “Regional situation: touch-and-remove”.)
When the challenge is initiated, a snapshot of the current required registry parameters is created and voting begins (see the Voting section), in which any token holder can participate. After the vote, a deposit of either the candidate or the initiator of the dispute is confiscated. The winning party receives a portion of the confiscated deposit (
DISPENSATION_PCT) in compensation for financial risk. The remaining part of the deposit is distributed among the participants of the voting majority in accordance with the weight of their tokens. Minority voting members do not lose or gain anything.
DISPENSATION_PCT, essentially, gives the challenger the confidence to win a vote. As a result of the gain, there will actually be a publication (issue) of challenging. If a special resolution (special dispensation) is determined, for example, at the level of 50%, then the challenger must be more than 66% sure of the possibility of victory. Why 66%? Because there is a 33% chance of losing the deposit completely and a 66% chance of making half the deposit: (0.33) (- 1) + (0.66) (0.5) = 0.
If the application is disputed, it is deleted, and the candidate may or may not become a member of the list. If the position of the list is disputed, the position may be deleted or not deleted.
Edge situation: touch-and-remove
If the candidate made a deposit, became a participant, and later the value of the current mandatory
MIN_DEPOSITincreased, the participant’s deposit will be smaller
MIN_DEPOSIT. If such a position is disputed, it is immediately removed from the list, and deposits of the challenging and list participants are returned to the owners. This is touch-and-remove.
Why and why such an approach? We assume that the size of deposits in disputes should be the same, so that the actions of the voters are not affected by the desire to divide the largest deposit (this will give them the greatest profit). Then why don't we equate the size of deposits when challenging to the size of deposits of the contested positions themselves? It is possible that the deposit due to fluctuations in the market price of the token has become cheaper than gas and opportunity costs. Participants will incur these costs if they initiate a dispute or vote. The touch-and-remove approach reduces the possibility of poisoning the registry with entries whose deposits are too small to challenge: active token holders will simply remove such positions at minimal cost.
In order to protect themselves from touch-and-remove after upgrading
MIN_DEPOSIT, members of the list can increase their deposits as much as they want, and any amount over and above
MIN_DEPOSITcan be withdrawn at any time. When challenging the size of the current
MIN_DEPOSITis fixed in the picture, and only this amount is allowed to put at stake.
Voting in the TCR should be token-weighted and follow the commit-reveal scheme. There are no other special requirements for voting, as long as the mechanism is effective in terms of token liquidity.
The token-weighted characteristic (the conditional weight of tokens) is important for holders who have invested the most tokens, which means that their voice in managing the registry is the most significant. Such holders will be the most prudent. And thanks to the commit-reveal scheme, voting stimulates participants exclusively to the greatest productivity. Token liquidity should be maximized to encourage participants to vote.
PLCR voting ( Partial Lock Commit Reveal Voting ) is the most effective token-based voting mechanism for TCR.
Registry settings should be adapted to the dynamics of changes in the market price of the internal registry token. For example, the price falls, there are hundreds of candidates for inclusion in the registry, and holders of tokens can not effectively handle all applications. Then you need to increase
So far, there is no definitive answer on how best to perform parameterization, i.e., in effect, manage the registry. For example, in AdChain, the principles of parameterization are the same as the principles of processing applications for inclusion in the registry. Here, another set of the same parameters is used, so for the proposal on reparameterization it
MIN_DEPOSITcan be much higher than if it were a question of including a new position. Reparameterization proposals are also disputed with the help of token deposits, they are placed both by the proposer and the challenger. Holders of tokens can vote for reparameterization of registry parameters or parameters of the reparameter itself.
Interesting TCR properties
Internal registry tokens are a necessary element of self-sufficient systems for public use. The TCRs themselves are the main enemies of capitalism, they perform a useful function at the lowest possible marginal costs.
Token-Managed Registries Fulfill Mike's Cryptosystems Manifesto Principles
TCR needs internal tokens. Using something else instead will disrupt the normal operation of the system. Holders of tokens should understand the pros and cons of their good or bad work, then they will have the motivation for the main task - to manage the registry. For example, the price of Bitcoin will not be affected by the decrease in demand for it in the registry lists. So, the holders will want to collect as many bitcoins as possible from the candidates with the help of false contests and collusion at the polls, pushing the interests of registry management to the background. And if the only purpose of the token is to use it when submitting applications to the registry, its price will vary depending on the demand for participation in the lists. The demand is affected by how well the holders manage the lists. The principle of the need token (token-necessity) in the TCR is respected.
The system is self-sufficient if it functions normally without the participation of its creators. In the TCR, no entry has any special privileges. All tokens are equivalent, and only the weight of the token determines the weight of privileges of its holder in the registry. The creator of the registry may disappear, and a closed incentive system will not suffer from this. TCRs are true decentralized systems. The principle of self-sufficiency is respected.
The system is publicly used (public utility) if it does not require permits, is free of rent and benefits. TCRs do not require permissions, they are completely decentralized, and the privileges in them are determined only by the conditional weight of tokens. Such registries do not require rent, as they will never be put at stake for the sake of encouraging someone to complete a task or to keep them from attacking. TCRs generate useful results in lists. The principle of public use is respected.
The main enemies of capitalism of the
System, creating a useful result with minimal marginal costs - these are the main enemies of capitalism. The result of the TCR is free: the lists are stored on the blockchain, either side can count them. Instead of giving money to a vendor for making a list, TCR consumers get the product of all vendors for free. Those are competing with each other in creating the best list that can appear on the free market.
Those who want to improve the quality of TCR can buy tokens at the market price, manage the registry qualitatively, stir up consumer interest, increase the demand of candidates for the token - and then sell their tokens, earning money on those who want to improve the registry. A holder of a token who is good at challenging and voting will secure a steady income by selling tokens obtained from confiscated deposits and without losing any fixed capital.
Thus, in an efficient market, internal registry tokens will eventually be optimally distributed among the subjects that use them most productively. In TCR, profitability and productivity are closely interrelated.
Attacks and defense against them
TCR is theoretically possible to attack. In addition, surely not all types of attacks are formulated and fixed. Below we discuss the known attacks and defenses against them.
Simple trolling A troll
tries to add “bad” positions to the “good” registry that do not meet the registry criteria. If the registry is well watched, such attacks are expensive and ineffective: the troll loses the deposit when the rational token holder successfully disputes the application. To overcome the rationality of the voters, a simple trolling attack must turn into an attack of a madman.
Attack of a Madman
A well-resourced attacker may have rational reasons to spend a lot of money on destroying the registry. If a useful list with almost zero marginal costs destroys businesses, then affected companies will probably not like it. The attacker buys at the market price the majority of protected from contested tokens with the right to vote and fill the registry with low-quality positions. The registry will be corrupted, the cost of tokens will collapse.
Fortunately, token-managed registries have protection against similar attacks, quite similar to those that are typical for Casper. In terms of finance, with an attack, 51% of the attackers' weapons can be destroyed with the help of hard forks. As Vitalik says, “the task is to make an attack of 51% extremely expensive, so that even the majority of collaborating validators cannot roll back the finalized blocks without extremely heavy financial losses. So heavy that even a successful attack will certainly lead to an increase in the price of the base currency, since the market will react to a reduction in the overall supply of coins more than an emergency hard fork to weaken the attack . ” In TCR, validators are token holders.
Probably, in practice at any time only a smaller part of the tokens will actively participate in the voting (see the “Bootstrapping” section), so the attacks of a madman will not be as expensive as the “attack on most validators” label implies. Reducing the passivity of token holders is an important open question in the TCR.
Not a token holder, but a member of the list deals with poisoning of the registry. The position is entered in the register, and after its quality deteriorates. For example, a higher education institution included in the list of high-quality educational institutions, thanks to this, raises the cost of education, but its graduates later discover that they cannot pay their tuition fees after 10 years.
Rational holders of tokens should identify this behavior and dispute the positions that poison the registry. Poorly studied aspect: poisoning can be relatively cheap, if the position of the list just waits for it to
MIN_DEPOSITincrease during the list, and if illegal actions are found, then you can leave the list using the touch-and-remove procedure. In this case, the position of the list does not lose the deposit, however, the subject himself loses his reputation and will no longer return to the list.
Dropping a coin and voting memos
Voters are not punished for bad decisions, so tokens holders may find it easier to “throw a coin” than to spend time on weighted scores. You can protect yourself from an attack if the voters are interested in maximizing the demand for a token. But it is not known to what extent these considerations will affect the emergence of a critical mass of voters, leveling the irresponsible behavior of others.
Throwing a coin is an attack that is not too dangerous: assuming a uniform distribution of votes as a result of throwing a coin, a few activists who hold tokens with any contest will tip the balance in favor of rationality.
Voting (vote memeing) occurs when participants vote only to be in the majority. From the point of view of motivation, it is similar to throwing a coin, but the result is worse: a minority of activists holding tokens will not tilt the balance in favor of rationality.
Coin tossing and voting memorialing are complex attacks because they are aimed at the limits of rationality of token holders (see “Limits of Rationality”).
Limits of rationality
There are strategies, rational "here and now", but harmful in the long run. Passively holding tokens is undesirable in itself, coin tossing and voting memos are rational, but over time they degrade the quality of the registry. What are the best strategies participants will follow? Can a situation arise when someone acts tactically, and someone strategically, and as a result, the quality of the lists will be average, lower than if the list were managed centrally?
TCR is peculiar to the dilemma of chicken and egg primacy. Consumers are not attracted to an empty list, and candidates do not want to participate in a list that is not interesting to consumers. In general, it will be difficult for the registry to gain the interest of any of the groups of participants in order to achieve a sustainable self-sufficient state. There are different opinions about the optimal approach to creating a registry-controlled token, and so far none of the approaches has turned into a clear pattern to follow.
One approach: a group of candidates in collaboration with “outdated” governing bodies (industry lobbies, advisory councils) form the initial set of participants. Motivation: use proven industry curators to create a convincing basic set of positions in the registry.
Another approach: initially, registry tokens are distributed among potential consumers and candidates. This gives the parties (otherwise disinterested) tangible motivation for self-nurturing the system.
Minimum Economy Size
What is the minimum economy required for decentralized list management? Is it economically decentralized to manage your shopping list? Will it be rational for the manufacturer of packaged goods and products to apply for inclusion in the register of positions that need to be purchased at the grocery store? Will the voters be able to manage the list, which is useful for buyers? How do voters know if there is enough cheese for a customer? What is the minimum consumer interest needed for decentralized list management?
Registry parameterization is currently not well developed. Perhaps the same AdChain parametrizer can be brought to constant instability. For example, setting a zero value for the
MIN_DEPOSITparameterizer. Then, without much effort, trolls will retain a zero value for an unlimited time
MIN_DEPOSIT, since after a successful initial attack, you can create many sentences that will later be processed and activated at any time. Protection against such an attack on the AdChain parameterizer depends on the diligence of the token holders. Registries will recover from the consequences of an oversight of holders and poisoning by means of challenging, but parametrizers can be irrevocably damaged even after one successful attack.
PS Unfortunately, in the article the author left aside the topic of launching a TCR system, that is, the issue of the primary distribution of the token and the filling of the registry with primary data. We are currently working on this question and are planning to stage a series of experiments. If you do not want to miss - subscribe to our blog and other social networks.