Token-Curated Registries, the Uses and Exploits

By William Entriken

6 minutes

What are they, and are they useful?

This research was originally funded and cross-posted with 0xcert.

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 James fast?,” “is Mary fast?,” “is Patricia 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 the four minimum components to make a TCR:

  1. Players can vote
  2. Players can commit money
  3. A result is calculated based only on the votes and the money
  4. Everybody agrees to support the outcome of the vote

In the real world #2 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’s list of benefactors:

[IMAGE FROM A MUSEUM DONOR LIST PLAQUE]

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.

[IMAGES OF CLIFFORD, SCOOBY-DOO, UNDERDOG]

[Clifford has a stamp on it with HUGE and a checkmark, Scooby-doo and underdog each have a stamp with an X and NOT HUGE on it]**

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:

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 will happen. 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:

The parameters are set to mitigate certain other conditions

The attacks on Augur are much more complex. I’ve got one, it is already acknowledged in the Augur white paper. This attack is out of scope of the Augur bug bounty program they announced this week so maybe I’ll write it up on my own.

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, if there is a liquid market for money and votes another attack is possible. 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% 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

▧

Comments

Discuss and share this topic anywhere. May we recommend: