The Layered TCR

Low-friction onboarding, and increase of rights from value added. Applications in access control, governance, identity, more.

Joint work with Dimitri de Jonghe and Fang Gong.

Abstract

This article introduces the Layered Token Curated Registry (LTCR), a new cryptographic building block. LTCRs are composed of layers of TCRs. They replace the rather harsh “you’re either in or out” approach of TCRs, with a step-by-step increase in rights and responsibilities as the actor adds more value and stake. They smooth onboarding and help maintain actor diversity. LTCRs can be applied to problems of access control, governance, identity, reputation, and more.

1. Introduction

Designing tokenized ecosystems, aka public blockchains, is not easy. However, the community has started to structure this better towards a practice of Token Engineering. A key part is to create re-usable building blocks, aka cryptoeconomic primitives. A great example is the Token-Curated Registry (TCR) which is a set. TCRs have stake-based incentives to enter and exit that set. They have been used as whitelists of good links (like adChain), good actors (like Ocean), and more.

TCRs imply a binary-valued membership: you’re either in the set, or not. Among other building blocks, there are Curation Markets, which have a continuous-valued membership. There are also Stake Machines, which are DAG-valued membership: DAGs with TCRs for nodes and staking for directed edges.

An important goal of tokenized ecosystems is: maximize the number of participants who can contribute to the ecosystem. With this goal, TCRs’ framing of “you’re in, or you’re out” is rather harsh. Imagine instead if the community can let new people in with low friction; yet not trusting the new entrant enough to give them the keys to the castle. But as a new community member adds more value, more stake, and spends more time in the system, their rights and responsibilities can increase. In short, could membership in the community be “shades of gray”?

TCRs have more challenges. First, a TCRs is sensitive to the initial community; its success is highly dependent on how well the first 50 or so agents are seeded. And even if that works out fine, a TCR is constantly at risk of being swamped by many bad actors joining at once, or a Sybil attack of one bad actor. These concerns could both be mitigated (though not fully erased) by a “shades of gray” framing.

My goal here is a “shades of gray” token machine with discrete-valued membership, where agents can increase their rank (layer), and with it, their rights and responsibilities.

The structure of the design is a composition of TCRs into layers: a Layered TCR (LTCR). An agent is a member of only one layer at a time, and each higher layer means higher rank. The rules to enter or leave a layer may be different for each layer (heterogeneous). We can frame a LTCR as a TCR with scope generalized to >2 discrete values; or a subset of Stake Machines drilling from a DAG into a fixed-length chain.

The rest of this article is organized as follows. Section 2 describes applications, and section 3 gives precedents. Section 4 describes the LTCR design. Hint: it’s simple! Section 5 describes diversity maintenance and parallels to evolutionary algorithms. Section 6 concludes.

2. Applications

Applications of LTCRs include:

Access Control / Permissions. Increased rank means increased authorization for a broader range of network services, or more rights within those services. For example, at the lowest level, you have no rights. As you go up the levels, you gain the ability to read files / directories, then write, then execute; akin to Unix file systems rwx permissions.

Increased rank means increased authorization for a broader range of network services, or more rights within those services. For example, at the lowest level, you have no rights. As you go up the levels, you gain the ability to read files / directories, then write, then execute; akin to Unix file systems rwx permissions. Governance. Increased rank means increased authorization to participate in network governance. E.g. at the lowest level, you have no governance rights. Higher up, you can run a validator node (e.g. in DPOS systems) and get corresponding block rewards. And at the very top, you’re able to vote on protocol governance updates.

Increased rank means increased authorization to participate in network governance. E.g. at the lowest level, you have no governance rights. Higher up, you can run a validator node (e.g. in DPOS systems) and get corresponding block rewards. And at the very top, you’re able to vote on protocol governance updates. Identity Authentication. Increased rank means increased authentication of a human’s identity. E.g. at the lowest level, you just have public key or DID. Perhaps one level up it’s vetted by an email or a social media profile. Higher up yet is KYC by a bank. Perhaps at the top is KYC by a country open to the world, like Estonia E-Residency. The exact levels depend on the nature of the application.

Increased rank means increased authentication of a human’s identity. E.g. at the lowest level, you just have public key or DID. Perhaps one level up it’s vetted by an email or a social media profile. Higher up yet is KYC by a bank. Perhaps at the top is KYC by a country open to the world, like Estonia E-Residency. The exact levels depend on the nature of the application. Block rewards. The higher the level, the more block rewards you get. E.g. there are 5 levels and block rewards are multiplied by 0.2, 0.4, 0.6, 0.8, 1.0 with respect to level. This easily combines with other layers, e.g. identity.

The higher the level, the more block rewards you get. E.g. there are 5 levels and block rewards are multiplied by 0.2, 0.4, 0.6, 0.8, 1.0 with respect to level. This easily combines with other layers, e.g. identity. Easy onboarding yet acknowledging experts. Low-friction onboarding for newcomers, yet greater benefits to those who have added value or stake over time. Ideally in a way where over time newcomers have a fighting chance to join the ranks of the more senior actors. This is the problem of diversity maintenance : ensure that that the tokenized ecosystem does not “get stuck” with incumbent actors blocking fresh entrants from being able to meaningfully contribute.

Low-friction onboarding for newcomers, yet greater benefits to those who have added value or stake over time. Ideally in a way where over time newcomers have a fighting chance to join the ranks of the more senior actors. This is the problem of : ensure that that the tokenized ecosystem does not “get stuck” with incumbent actors blocking fresh entrants from being able to meaningfully contribute. Reputation systems. Each of the above can be framed as reputation systems, but with reputation defined differently in each context.

3. Precedents

The Web 1.0 and 2.0 worlds have several precedents for discrete-valued membership. Here are a couple.

Wikipedia. The first line of engagement with Wikipedia is to simply go to the website and read content. You’re a newcomer with few rights and responsibilities. To engage more is about writing and editing, following the Wikipedia rules You start with ability to edit less contentious pages like “Groundhog.” But, you need to increase your rank in the Wikipedia community in order to edit a page like “George W. Bush”. C4 Process. C4 is a modern process for software development that puts community first. The highly successful ZeroMQ community and product was built with it. C4 has four progressive layers of engagement: User of the software → Contributor → Maintainer → Administrator. C4 has specific rules to get promoted. C4 founder Pieter Hintjens’ book Social Architecture elaborates on the motivations and specifics of the C4 design.

Many other precedents abound, both online and off, from academic ranks (top tier being “distinguished professor”) to autonomous cars (top tier being “fully autonomous”).

4. The Layered TCR Design

From the target applications and from precedents, we see:

They are ranking systems with 3–10 ranks. You can only occupy one rank at a time.

You need to pass specific criteria to get promoted (increase rank) but you can also get demoted (decrease rank) and even get removed from the system.

You start as a newcomer with few rights and responsibilities. But as you spend time in the community, add stake, or add value, it could be useful if you can increase your rank, i.e. grow your rights and responsibilities

The Layered Token Curated Registry (LTCR) draws on those observations. Its design manifests the goal of discrete-valued membership in a token-curated setting. It is composed of layers of TCRs of increasing rank. It draws on these patterns. Higher ranks imply more rights and responsibilities.

The Layered TCR (LTCR)

There are clear rules for promotion, based on more stake and value added:

New actors enter the system with rank 1.

To get promoted to the next level, the actor must pass that level’s entry criteria. This criteria might include: staking more tokens, spending a minimum amount of time in the system (e.g. 3 months), or provably adding some minimum value to the system so far (e.g. have mined 5 blocks). If they pass these criteria, they are promoted, and with that promotion they gain increased rights (e.g. they can edit Bush’s bio!) or responsibilities (e.g. they must review a minimum number of pull requests).

(e.g. they can edit Bush’s bio!) or (e.g. they must review a minimum number of pull requests). If an actor no longer meets the criteria for a level (e.g. they did not fulfill their responsibilities), then they get demoted.

“Value added” is contribution to the network value. This might be in the form of proofs for which one gets block rewards, such as Bitcoin’s proof of solving a cryptographic puzzle (for network security) or Filecoin’s Proof of Space time (for storage).

As a general design, that’s it! It’s meant to be simple and flexible on purpose.

5. Diversity Maintenance & Relation to Layered EAs

Introduction

This final section is a bonus/advanced section.

Elsewhere, I’d described how tokenized ecosystems are a lot like Evolutionary Algorithms (EAs), and how we can use best practices for EAs for tokenized ecosystem design. This section shows another example of that, for advanced LTCR designs.

Ideally, a tokenized ecosystem has low-friction onboarding for newcomers, yet greater benefits to those who have added value or stake over time. This is the problem of diversity maintenance: ensure that that the tokenized ecosystem does not “get stuck” with incumbent actors blocking fresh entrants from being able to meaningfully contribute.

The Problem of Diversity Maintenance in EAs

EAs are optimization algorithms that mimic “survival of the fittest” evolution to return “fit” individuals. They typically follow an algorithm like:

Randomly generate e.g. 1000 individuals. Repeat the generational loop e.g. 1000 times:

Evaluate each individual’s fitness; e.g. measure power of a circuit.

each individual’s fitness; e.g. measure power of a circuit. Select parents and discard the rest ; e.g. keep the top 50%.

; e.g. keep the top 50%. Create children by via operators on the parents, e.g. mutation which randomly perturbs a parent design.

The aim is to end up with high-fitness individuals. However, this doesn’t always happen. The population can “get stuck” in some niche of the design space; it’s converged prematurely.

To counter this, we wish to keep the population diverse enough so that it doesn’t prematurely converge. That is, we want diversity maintenance.

One trick is simply to have a larger population; but that runs against computational constraints (and can’t help us in tokenized ecosystems!).

Researchers have proposed many other diversity maintenance ideas. One oft-tried ideas was to inject say 10% of randomly-created individuals each generation. However, this works poorly because the random individuals generally have no chance against the other individuals who have benefited from many generations of optimization. The older individuals may not have been optimal, but they creamed the newcomers.

Another popular idea was fitness sharing. Here, all individuals in the same region share fitness collectively, in a kind of local zero-sum setting. However this system had no way to get “fresh blood” and could therefore readily get stuck.

Diversity Maintenance by Layers: Introduction

In the mid-2000s, an idea emerged inspired by K-12 schools. In schools, grade 1 kids only have to compete with grade 1s, grade 2 with grade 2, and so on. A grade 1 doesn’t get pitted against a grade 12, as it would be unfair. Periodically, smart kids get to skip grades.

The idea was: let’s do the same with EAs! Each grade becomes a layer. Each layer has its own population of individuals. Individuals in a layer can only compete with that layer. They have means to get promoted. And smart individuals get to skip grades.

Layered EA algorithms manifested this idea in two separate ways: separating by age, and by fitness.

Diversity Maintenance by *Age* Layers

In the EA literature, Greg Hornby’s Age-Layered Population Structure (ALPS) uses layers of populations, where it segregates layers by age. Each sub-population has a different maximum age: 0–9 generations for layer 0, 10–19 generations for layer 1, etc.

Below is an example ALPS architecture. It has 9 age layers. Each layer proceeds mostly like a typical EA. Except:

Every 20 generations, randomly-generated individuals enter at the layer k=0.

When layer k=1 is doing selection, it looks not only at individuals in its own layer, it also considers layer k=0 individuals. In this fashion, well-performing individuals can get promoted to higher levels quickly. And they better, because any layer 0 individuals that don’t make it into layer 1 by age 19, they get deleted by the new random individuals about to enter.

The same rules apply for each pairing of levels (k-1, k). The top layer does not have an age limit.

Example ALPS architecture. From here.

In ALPS, newcomers — randomly generated individuals — get to enter without getting creamed by older, more fit individuals. This is how ALPS maintains diversity.

In practice, ALPS works remarkably well. I’ve personally used it in several EA designs. Below is an example of ALPS convergence, trying to minimize cost (called “fitness” in the image). L0 (layer 0) has the youngest and least-fit individuals; then higher / older levels do progressively better.

Example ALPS convergence. From here.

Application to LTCRs. We can use ALPS ideas for Layered TCRs. First, note the similarities already between a LTCRs and ALPS: they are both layers of populations, where each agent “runs around and does its thing”. Each has rules for entering and exiting layers. Each is optimizing.

The new idea to bring from ALPS is to add age constraints. Specifically: each TCR layer has a maximum age, like shown below. If an actor exceeds the age for that TCR, then they are ejected from the system and lose their stake. Actors can get promoted to a next layer as soon as they’ve hit the promotion rules for that layer.

Layered TCR with age constraints, per layer.

This incentivizes the actor to “get a move on” and contribute actual value to get promoted before they exceed the age threshold. And if they’re super-efficient about adding value, then they get promoted long before they hit their time constraints.

Therefore individuals who make major contributions yet have spent relatively less time in the system can get promoted. And, old individuals who have stopped adding value are ejected.

The result? Newcomers actually have a chance, yet convergence doesn’t get stuck.

One potential issue: actors at the top level “rest on their laurels” and do nothing, because they have no age limit and they are at the top based on previous value added. A possible fix is a “reputation” score that’s a function of value added, but reputation fades over time (like Colony).

Diversity Maintenance By *Fitness* Layers

Rather than layers that segregate by age, we can also segregate by fitness. Here, I describe two variants: HFC and Partial Swaps.

HFC. In Jianjun Hu’s Hierarchical Fair Competition (HFC), each layer has a different minimum and maximum fitness. Periodically, randomly-generated individuals are injected into the lowest-fitness layer. But the new individuals don’t get annihilated by highly-fit individuals which are at the highest levels.

In my experience, HFC works quite well. However, setting fitness thresholds can be challenging on some problems. One solution is “partial swaps”.

Partial Swaps (PS). Rather than strict fitness boundaries between layers, PS has softer, stochastic boundaries. It periodically swaps lower-fitness individuals in a higher layer with higher-fitness actors from a lower layer. And, it lets layer K-1 individuals join layer K without getting immediately creamed by layer K individuals; the new entrants get a few generations to prove their worth at that layer.

Application to LTCRs. We can adapt this “segregate by fitness” idea directly into Layered TCRs. Fitness could be a function of value added, stake, and time. It could be a proxy for reputation, depending how reputation is defined. For example: fitness starts at 0.0; it increases with each (value added) * (stake at the time); and decreases with a half-life.

Diversity Maintenance Variants

The following tweaks might be useful for certain problems.

Demote vs. eject. Rather than kicking out anyone who no longer fulfills a criteria for a layer, simply demote them to a lower layer. Only eject the bad actors. This is useful because may occasionally make some contributions and benefit the ecosystem which is desired behavior.

Rather than kicking out anyone who no longer fulfills a criteria for a layer, simply demote them to a lower layer. Only eject the bad actors. This is useful because may occasionally make some contributions and benefit the ecosystem which is desired behavior. Fixed-size vs. unlimited-size layers. In some cases, we may want to encourage competition at a given layer, e.g. so that the overall system keeps “upping the ante”. Having fixed-size populations at higher layers is one approach to do this. E.g. the top level is 25 individuals, next is 50, then 100, 200, etc; only the bottom level is unlimited. However this must be done with care, as it might lead to oligopoly.

6. Conclusion

In this article, I presented the Layered Token Curated Registry (LTCR), a new cryptographic building block for Token Engineering. LTCRs are composed of layers of TCRs. They replace the rather harsh “you’re either in or out” approach of TCRs, with a step-by-step increase in rights and responsibilities as the actor adds more value and stake. LTCRs can be applied to problems of access control, governance, identity, and more.

LTCRs have close parallels to work in layered EAs which segregate by age or fitness. Specific LTCR implementations can leverage the learnings from EAs to help diversity maintenance: letting newcomers enter the ecosystem without being swamped by experienced players, and preventing premature convergence in TCRs.

Appendix: History and Related Work

Stake Machines. While working on Ocean and other projects, Dimitri de Jonghe came up with Stake Machines. Dimi, myself (Trent) and others in the Ocean / BigchainDB realized that a highly useful subset was chains rather than DAGs, in particular for systems needing rank for rights & responsibilities. This realization led into…

…an earlier appearance of the concept, in Ocean. We actually described this idea briefly in the Ocean whitepaper (section 14.2 “Extended Functionality: Stake Machines”). Since then, we’ve found the concept helpful in many token design conversations, and was worth fleshing out and sharing with the community. The result is this article :)

gTCRs. The day we were set to publish this, our friends at weeve published a related idea they called Graded Token Curated Registries (gTCRs). gTCRs start with TCRs and replace voteIn with voteUp, and replace voteOut with voteDown. From that, a graded curation list can be generated.