Why Decentralized Identity Is Essential To Scaling the Ethereum Blockchain

Decentralized Identity Is “Layer 3” of Ethereum Scaling. Perhaps?

The Ethereum Blockchain will not scale without decentralized identity.

jump to 23:00 to hear Vitalik talk about the importance of self-sovereign authentication systems.
Ultimately if self-sovereign user authentication technologies ends up totally failing, then that means it is very difficult for the blockchain space to reach substantial mass adoption. Or at least in a way that achieves a lot of its promises. -Vitalik Buterin

Bold statement. I know… But I have the anecdotal evidence to back it up.

Yes. We have Sharding, Generalized State Channels and Plasma Chains.

However, those technologies are concerned with scaling transaction limits. It’s essential we start to think about the Ethereum blockchain in 2 categories:

  1. Blockchain Transaction System Design (Sharding, Plasma, etc…)
  2. Distributed Application Mechanism Design (Sybil Resistance)

The Blockchain Transaction Systems Design solutions don’t address the requirements for more complex game theory and incentives design in the Distributed Applications Mechanism Design layer.

Don’t get me wrong, solutions like Sharding and Generalized State Channels are absolutely essential to scaling the Ethereum blockchain, both horizontally and vertically. But, those scaling solutions don’t address the problems of mechanism design in distributed systems.

I’m excited for Layer 1 and Layer 2 solutions, because blockchain.

But, I’m more excited for Layer 3, decentralized identity, because people!

Whether you’re building a Community Fraud Prevention System, Token Curation Registry, a Distributed Autonomous Organization, Collusion Resistant Blockchain Game or any other number of distributed application systems that can be easily “gamed” via trivially generated public/private key-pairs you will quickly realize decentralized identity is absolutely essential.

Sybil resistance is the industry jargon.
And it’s essential for meaningful decentralized mechanism design.

For the Ethereum ecosystem to reach maximum velocity i.e. banking the unbanked, empowering the disenfranchised and building equitable systems of cooperation, it’s absolutely essential we start to focus on the why of Layer 3.


Know your ABC’s — always be creating!

As I mentioned before, the Ethereum blockchain can essentially be divided into 2 categories in regards to scaling:

  1. Blockchain Transaction System Design — Layer 1 + 2 Scaling
  2. Distributed Application Mechanism Design — Layer 3 Scaling

The difference between these 2 categories, is the focus on the varying requirements across the Ethereum stack. Layer 1 and Layer 2 are primarily focused on scaling the transaction limits, while Layer 3 is focused on utilizing these new transaction ceilings and introducing more nuanced mechanism design mechanics into the ecosystem.

Sybil Resistance

The ability to easily generate 1,000’s of public/private keys is both a curse and blessing for the Ethereum blockchain. It’s great, because anyone can easily generate a new wallet in milliseconds. However, it’s not so great if social trust and reputation needs to be associated with the public/private key-pairs.

In a Sybil attack, the attacker subverts the reputation system of a peer-to-peer network by creating a large number of pseudonymous identities, using them to gain a disproportionately large influence. A reputation system’s vulnerability to a Sybil attack depends on how cheaply identities can be generated, the degree to which the reputation system accepts inputs from entities that do not have a chain of trust linking them to a trusted entity, and whether the reputation system treats all entities identically.

Mechanism Design

The term mechanism design refers to the ability to construct non-zero sum games using properly aligned incentives with a strong focus on engineering. Or at-least that’s how I like think about it.

For example all cryptocurrencies utilize mechanism design.

What is a cryptocurrency? It’s a string of characters on a public ledger. The cryptocurrency or token has no intrinsic value. None. Zero. Nada. However, because we’ve all reached the collective hallucination that these particular string of characters are valued at $500+ we can start to play new and interesting games, because we’ve introduced monetary incentive into our mechanism design capabilities — and it’s on a global distributed network!


Mechanism design is a field in economics and game theory that takes an engineering approach to designing economic mechanisms or incentives, toward desired objectives, in strategic settings, where players act rationally. Because it starts at the end of the game, then goes backwards, it is also called reverse game theory. It has broad applications, from economics and politics (markets, auctions, voting procedures) to networked-systems (internet interdomain routing, sponsored search auctions).

Now that we some context for mechanism design, let’s get back to the original point. Ethereum’s Layer 3 scaling solutions — decentralized identity.

Playing The Game of Games

What are smart contracts? They’re games. Games using mechanism design to incentivize a certain behavior or desired outcome. And what do people do with games? They play them. And since, code is law we have to ensure these rules are properly configured for the development of more complex, non-zero sum games that increase humanities ability for happiness.
That’s the dream.

I started by listing a number of different Ethereum blockchain applications:

  1. Community Fraud Prevention Systems
  2. Trustable Token Curation Registries
  3. Distributed Autonomous Organization
  4. Collusion Resistant Blockchain Games

What do all of these distributed applications have in common?

All of these distributed application examples require sybil resistance to properly function using a decentralized blockchain. Without including decentralized identity, or similar sybil resistance mechanisms, these applications will ultimately fail. And here is why…

Let’s start with Community Fraud Prevention System as an example.

Recently, I spoke to an Engineer on the Ujo team, regarding preventing fraudulent music uploads. It’s a problem when anyone can upload music to a decentralized marketplace, because intellectual property rights.

For example, if I pretend to be Kanye West and upload his albums to a decentralized marketplace, but I’m not Kanye, that’s not coooool man.

To prevent such an atrocity, it was proposed the community can help monitor fraudulent music uploads: notice a suspicious upload, report the potential fraud and get rewarded for maintaining a trustworthy, decentralized music marketplace.

What’s the reward for preventing fraud? Economic incentives. Cryptocurrency.

Stop right there… Houston we have a problem — “money” is involved!

What If I generate 100’s of accounts (public/private key-pairs), upload music without the proper consent and report all of my uploads as fraudulent?

Basically I game the system by both uploading music and reporting the fraud.
That’s a problem.

I can make boatloads of money via my amazing Engineering skills, by trivially generating new Ethereum accounts, writing a handful of scripts to autonomously interact with the distributed application and basically letting loose my army of bots to play the Community Fraud Prevention System game.
And win! But that’s not the intent of the game.

The Community Fraud Prevention System game was not designed to pay Kames fat stacks of 💰 cash, but rather to prevent people abusing Kanye West!

That’s the problem. Now what’s the solution?

Decentralized identity systems, like uPort, provide the required buidling blocks to overcome these challenges. We need to prevent people from playing subversive “meta” games atop our originally intended games, but the question always remains “How?”

Easy. The answer is trusted decentralized identities.

Ethereum promises trust derived via cryptography.

uPort creates trust, which can not be computationally derived.

Computers are great at performing calculations with 1's and 0’s. However computers fail swiftly when attempting to calculate information, which is not stored in bits and bytes.

By combining the power of cryptographically verifiable calculations with the intuitive power of humans, we can reach an equilibrium of trust between the digital and physical worlds.

The Multiple Layers of Trust

How much trust is required in distributed applications mechanics is entirely dependent on the incentives and cost for “bad” actors to manipulate the game.

The smaller the reward for “social engineering” the game, the less likely trust from decentralized identity is required.

You can trust me. Or can you?

For example a Rinkeby account I use to develop and test smart contracts is: 0x908bd5e5e5636c84a16d2541af4696ab53dafe07

I’m Rinkeby rich baby!

But, how can you actually know that I own that account? Well… You can’t.

I could 100% be lying. I have dope Photoshop skills too, so maybe I just created a fake screenshot, so I could trick you into believing I’m the rightful owner of the public key.

How does that saying go again… “Trust, but verify.”

To create sybil resistant protocols for the Ethereum blockchain, collectively we need the ability to add trust to public keys.

My favorite example of introducing sybil resistant features into decentralized networks is key signing parties, because they demonstrate the importance of adding trust to a network of humans in a digital world.

Key signing parties provide the mechanisms to associate a single person with a single public key. Why is this important?

Humans are the key 😄 to creating trustable public/private key-pairs.

Let’s imagine in the Community Fraud Prevention System game built by Ujo, the only people allowed to report fraudulent music uploads are trusted public keys.

For example, maybe Ujo requires decentralized identities have to verify ownership of a Twitter and Facebook account to report fraudulent uploads. Or perhaps they use a third-party service like Onfido to verify a Drivers License or Passport. Depending on the economic incentives of manipulating the game, different levels of trust requirements might be introduced to the system.

Even better… Ujo can host an amazing concert/performance, where everyone is encouraged to participate in a key signing party and everyone verifies each other identities face-to-face, so third-party service like Twitter or Onfido is never even required — hashtag winning!

Remember it’s all about the people always!

These verified and trusted public keys can now be used in Ujo’s Community Fraud Prevention System game, knowing each public key has a verified identity managing the private signing key.

The more people who have verified a public key, the better.

If only 1 or 2 people have verified another decentralized identity…meh… that’s O.K. but not great. However, on the hand if 100’s of people have verified my decentralized identity, the likelihood of all those people lying on my behalf dramatically decreases and the more external actors can trust my claims surrounding my decentralized identity.

the ever expanding Web of Trust

Spoiler Alert

uPort is working on ready-to-go boilerplate for organizations to quickly create distributed applications with ready-to-go decentralized identity verification methods.

You get a DID! And, you get a DID. We all get DIDs!

Trustable Token Curation Registries

Not convinced…yet? No problem! How about another example?

Token Curation Registries are next.

Token Curation Registries are a novel concept, that incentivize, via mechanism design, the curation of high-value information in list format. Simple. Straight-forward. And easy to understand.

A token-curated registry uses an intrinsic token to assign curation rights proportional to the relative token weight of entities holding the token. So long as there are parties which would desire to be curated into a given list, a market can exist in which the incentives of rational, self-interested token holders are aligned towards curating a list of high quality. Token-curated registries are decentrally-curated lists with intrinsic economic incentives for token holders to curate the list’s contents judiciously.

Right… but how do you assign curation rights at scale?

Once again, it’s possible to play a “meta” game, without sybil resistance.

Since Ethereum accounts are pseudo-anonymous, 1 person can theoretically own 1,000’s of accounts and the digital community wouldn’t be the wiser. And if those 1,000’s of accounts are all given curation/voting rights on a particular Token Curation Registry, and sybil resistance wasn’t a core part of the game design … well that’s not particularly fault tolerant, now is it?

In short, if decentralized identity and sybil resistant features are not included at the core of Token Curation Registries at scale, then we have no hope for practically building high-value TCRs, because the incentive to play a “meta” game will outweigh the benefits of playing the originally planned game.


The Ethereum ecosystem requires strong sybil resistance mechanisms, if we as a community intend to reach maximum velocity. As blockchain Developers and Engineers start to think about building scalable distributed applications, it’s critical we think about system and mechanism designs from end-to-end.

Everything is a game. Code is law. And it’s up to us to protect the users.

Layer 1 and Layer 2 Ethereum are essential scaling solutions focused on optimizing the Blockchain Transaction System Design layer.

Layer 3 scaling solutions, decentralized and sybil resistance, are required for the Distributed Application Mechanism Design layer.