What are Token-Curated Registries, and are they useful?
Executive summary
A Token-Curated Registry (TCR) is a voting game where players commit money and vote, then some rules (based only on the money and the votes) register a consensus result.
That explains the “registry” part, but what about the “curation”? Well, that is just one application of this game. You can vote on questions like “is Bob fast?”, “is Mary fast?”, “is Steve fast?”, then the outcome will be a consensus of the players representing a list of which people are fast.
In blockchain applications, people are always thinking about how to design a system so that it does not depend on the stewardship of the creator. A TCR does not depend on stewardship of the creator, it depends only on the money and the votes. For this reason, there is much interest in TCR. In the world of agency systems (web 2.0) we might say “our application needs to access the weather, let’s plug into the Weather.com API,” but in the world of rules-based systems (web 3.0) we ask “we need stock pricing data, how valuable is that to us, and how expensive shall we make it for somebody to give us false information?”
There are many assumptions and design details to make a useful TCR. And, of course, assumptions and details turn into attacks and exploits if not implemented properly. Such is the topic of this paper.
Formal definition
These are three minimum components to make a TCR:
- Players can vote
- Players can commit money
- A result is calculated based only on the votes and the money
- Everybody agrees to support the outcome of the vote
In the real world, #3 is not necessary — many countries hold an election for their leader without charging money. However, in this paper, we are considering applicability to blockchain systems, where anybody can create an arbitrarily large number of accounts with ease. Therefore a headcount is insufficient, the heads are not valuable. We need something valuable. For our concerns here it is not important which account of value is used, so we just call it money. (This is where “token” in TCR comes from.)
Maybe the simplest example of a TCR is your local museum, library or park’s list of benefactors:
People send money to the museum, whoever sends the most gets their name engraved at the top of the list. We can audit the museum’s books to confirm the donations are correct. We assume somebody does that. Also, we assume if somebody pays more than the top person and the list is not updated then they will flip out and cause the list to be updated. This perfectly meets the definition of a TCR.
More useful systems
Not everybody is a benefactor. Usually, we commit money to get a more valuable thing in exchange.
A predicating system
Predicates are “yes/no” questions that apply to an independent variable. Clifford the Big Red Dog is huge, Scooby-Doo is not huge, Underdog is not huge. Here “huge” is the predicate and the dogs are the independent variable.
Mike Goldin’s paper, “Token-Curated Registries 1.0,” describes and motivates a class of systems with “intrinsic economic incentives for [players] to curate the list’s contents judiciously.” The paper argues that we can expect the TCR to produce true results (i.e. the consensus result matches an objective consideration of the predicate) if a few conditions are met:
- Calling a vote costs a significant amount of money
- Voting is slow and a large quorum is established
- Voting is relatively inexpensive
- If the consensus result matches the player’s vote they make money, otherwise they lose money, and the amounts are considerable
- Being on the list is valuable (“top-selling albums” not “restaurants with health violations”)
- There is a significant monetary incentive to players if the results are true
- The monetary incentives for true results exceed the external incentives for false results
Each condition listed above includes an adjective “significant”, “valuable”, etc. These are all complex design details and are based on value as from the perspective of players. And therefore, each design detail is a potential exploit if you can violate the conditions. Just one example, if you can make voting much more expensive by requiring players to do actual research to vote then this may violate system design assumptions.
But overall there is one fundamental weakness of Token-Curated Registries 1.0. The system must be designed and parameterized so as to support the conditions above, and this requires a knowledge of the problem space. But the problem space will change as the monetary incentives change (Goldin’s “token” value), and the voting cost changes, and the value of being on the list changes, and the number and types of players change. Therefore it will be necessary for the application owner to reset the parameters. And this violates formal definition #3 above for Token-Curated Registries.
Goldin’s design implements a separate system for each set of predicates. The monetary incentives are set using a token and value of the token is presumed to be based on the quality of the list. However, a general truth reporting system does not require separate systems.
A truth reporting system (“oracle”)
Augur is a futures betting market, and it requires a trustworthy input of the actual outcome of future events. Specifically, you bet on whether “yes/no” a specific event happens. Today we are only concerned with the event reporting part. This is a Token-Curated List where players vote to predicate “yes” for events that happened and “no” for events that didn’t happen. The system design uses a universe fork and multiple levels of review to achieve consensus on truth. The system rests on several conditions:
- Voting is relatively inexpensive
- A large quorum is established
- All open interest is identified by the system
The parameters are set to mitigate certain other conditions
- Open interest is controlled (the betting market shows the upside which is available to people if they would lie when reporting events) and significantly lower than the money at risk to event reporters
- The forking costs players money if they vote different from the consensus result
The attacks on Augur are much more complex. But they are well known and possible.
The exploits
These attacks apply to all TCR systems.
51% attacks
You have probably heard of the 51% attack. A formal wording would be: in a majority-vote system, anybody who can cast a majority of votes will control the system. Since TCRs depend only on the money and the votes, then 51% of the money can buy the system (if the rule is a majority vote wins). A system that employs a supermajority is cheaper to attack, you only need one share more than the number of votes necessary to block something.
There are also some practical considerations — the price of an attack might go up or down if people realize an attack is underway. See also the Borg attack.
34% attacks
Once 51% of votes are cast in one way, all remaining votes are useless (assuming a winner-take-all system). The obvious strategy for those voters is to follow the majority. Otherwise, they will lose money without having any impact on the outcome. Likewise, the people that cast the 49th and 50th percent votes do not need to do much diligence if they expect some of the subsequent voters will vote with the crowd.
Depending on the system there will be some number, let’s say 34%, where your votes plus random votes, plus people voting with the majority can be expected to vote however you like, regardless of the predicate.
One-vote attacks
But actually, there is a liquid market for money and votes. The mechanics of the game may make it so that the cost of research plus voting is so expensive that it is favorable to vote for the expected majority. In this case, 34% of attacks lead to 25% and 21% and 17% attacks. Eventually, a single vote which is published is enough to attack the system.
Antidote: The commit-reveal mechanism should be implemented in such a way that if somebody learns your reveal challenge then they can take your money and invalidate the vote. Unfortunately, this may be impossible to completely enforce on-blockchain.
Borg attack
A third-party can guarantee that players will be part of the majority voting block if players assign their vote to the Borg. The existence or threat of a Borg attack decreases the cost of a 34% attack.
References
- Goldin, Mike. Token-Curated Registries 1.0. https://medium.com/@ilovebagels/token-curated-registries-1-0-61a232f8dac7. Sep 14, 2017.
Originally published at 0xcert.org.
