2022 Jun 12
See all posts

Special thanks to Shrey Jain and Puja Ohlhaver for substantial feedback and review

Recently, there has been a growing amount of interest in using blockchains for not-just-financial applications. This is a trend that I have been strongly in favor of, for various reasons. In the last month, Puja Ohlhaver, Glen Weyl and I collaborated on a paper describing a more detailed vision for what could be done with a richer ecosystem of soulbound tokens making claims describing various kinds of relationships. This has led to some discussion, particularly focused on whether or not it makes any sense to use a blockchain in a decentralized identity ecosystem:

It’s worth zooming out and asking a broader question: where does it make sense, in general, to use a blockchain in non-financial applications? Should we move toward a world where even decentralized chat apps work by every message being an on-chain transaction containing the encrypted message? Or, alternatively, are blockchains only good for finance (say, because network effects mean that money has a unique need for a “global view”), with all other applications better done using centralized or more local systems?

My own view tends to be, like with blockchain voting, far from the “blockchain everywhere” viewpoint, but also far from a “blockchain minimalist”. I see the value of blockchains in many situations, sometimes for really important goals like trust and censorship resistance but sometimes purely for convenience. This post will attempt to describe some types of situations where blockchains might be useful, especially in the context of identity, and where they are not. This post is not a complete list and intentionally leaves many things out. The goal is rather to elucidate some common categories.

User account key changes and recovery

One of the biggest challenges in a cryptographic account system is the issue of key changes. This can happen in a few cases:

1. You’re worried that your current key might get lost or stolen, and you want to switch to a different key
2. You want to switch to a different cryptographic algorithm (eg. because you’re worried quantum computers will come soon and you want to upgrade to post-quantum)
3. Your key got lost, and you want to regain access to your account
4. Your key got stolen, and you want to regain exclusive access to your account (and you don’t want the thief to be able to do the same)

[1] and [2] are relatively simple in that they can be done in a fully self-sovereign way: you control key X, you want to switch to key Y, so you publish a message signed with X saying “Authenticate me with Y from now on”, and everyone accepts that.

But notice that even for these simpler key change scenarios, you can’t just use cryptography. Consider the following sequence of events:

• You are worried that key A might get stolen, so you sign a message with A saying “I use B now”
• A year later, a hacker actually does steal key A. They sign a message saying with A saying “I use C now”, where C is their own key

From the point of view of someone coming in later who just receives these two messages, they see that A is no longer used, but they don’t know whether “replace A with B” or “replace A with C” has higher priority.

This is equivalent to the famous double-spend problem in designing decentralized currencies, except instead of the goal being to prevent a previous owner of a coin from being able to send it again, here the goal is to prevent the previous key controlling an account from being able to change the key. Just like creating a decentralized currency, doing account management in a decentralized way requires something like a blockchain. A blockchain can timestamp the key change messages, providing common knowledge over whether B or C came first.

[3] and [4] are harder. In general, my own preferred solution is multisig and social recovery wallets, where a group of friends, family members and other contacts can transfer control of your account to a new key if it gets lost or stolen. For critical operations (eg. transferring large quantities of funds, or signing an important contract), participation of this group can also be required.

But this too requires a blockchain. Social recovery using secret sharing is possible, but it is more difficult in practice: if you no longer trust some of your contacts, or if they want to change their own keys, you have no way to revoke access without changing your key yourself. And so we’re back to requiring some form of on-chain record.

One subtle but important idea in the DeSoc paper is that to preserve non-transferability, social recovery (or “community recovery”) of profiles might actually need to be mandatory. That is, even if you sell your account, you can always use community recovery to get the account back. This would solve problems like not-actually-reputable drivers buying verified accounts on ride sharing platforms. That said, this is a speculative idea and does not have to be fully implemented to get the other benefits of blockchain-based identity and reputation systems.

Note that so far this is a limited use-case of blockchains: it’s totally okay to have accounts on-chain but do everything else off-chain. There’s a place for these kinds of hybrid visions; Sign-in With Ethereum is good simple example of how this could be done in practice.

Modifying and revoking attestations

Alice goes to Example College and gets a degree in example studies. She gets a digital record certifying this, signed with Example College’s keys. Unfortunately, six months later, Example College discovers that Alice had committed a large amount of plagiarism, and revokes her degree. But Alice continues to use her old digital record to go around claiming to various people and institutions that she has a degree. Potentially, the attestation could even carry permissions – for example, the right to log in to the college’s online forum – and Alice might try to inappropriately access that too. How do we prevent this?

The “blockchain maximalist” approach would be to make the degree an on-chain NFT, so Example College can then issue an on-chain transaction to revoke the NFT. But perhaps this is needlessly expensive: issuance is common, revocation is rare, and we don’t want to require Example College to issue transactions and pay fees for every issuance if they don’t have to. So instead we can go with a hybrid solution: make initial degree an off-chain signed message, and do revocations on-chain. This is the approach that OpenCerts uses.

The fully off-chain solution, and the one advocated by many off-chain verifiable credentials proponents, is that Example College runs a server where they publish a full list of their revocations (to improve privacy, each attestation can come with an attached nonce and the revocation list can just be a list of nonces).

For a college, running a server is not a large burden. But for any smaller organization or individual, managing “yet another server script” and making sure it stays online is a significant burden for IT people. If we tell people to “just use a server” out of blockchain-phobia, then the likely outcome is that everyone outsources the task to a centralized provider. Better to keep the system decentralized and just use a blockchain – especially now that rollups, sharding and other techniques are finally starting to come online to make the cost of a blockchain cheaper and cheaper.

Negative reputation

Another important area where off-chain signatures do not suffice is negative reputation – that is, attestations where the person or organization that you’re making attestations about might not want you to see them. I’m using “negative reputation” here as a technical term: the most obvious motivating use case is attestations saying bad things about someone, like a bad review or a report that someone acted abusively in some context, but there are also use cases where “negative” attestations don’t imply bad behavior – for example, taking out a loan and wanting to prove that you have not taken out too many other loans at the same time.

With off-chain claims, you can do positive reputation, because it’s in the interest of the recipient of a claim to show it to appear more reputable (or make a ZK-proof about it), but you can’t do negative reputation, because someone can always choose to only show the claims that make them look good and leave out all the others.

Here, making attestations on-chain actually does fix things. To protect privacy, we can add encryption and zero knowledge proofs: an attestation can just be an on-chain record with data encrypted to the recipient’s public key, and users could prove lack of negative reputation by running a zero knowledge proof that walks over the entire history of records on chain. The proofs being on-chain and the verification process being blockchain-aware makes it easy to verify that the proof actually did walk over the whole history and did not skip any records. To make this computationally feasible, a user could use incrementally verifiable computation (eg. Halo) to maintain and prove a tree of records that were encrypted to them, and then reveal parts of the tree when needed.

Negative reputation and revoking attestations are in some sense equivalent problems: you can revoke an attestation by adding another negative-reputation attestation saying “this other attestation doesn’t count anymore”, and you can implement negative reputation with revocation by piggybacking on positive reputation: Alice’s degree at Example College could be revoked and replaced with a degree saying “Alice got a degree in example studies, but she took out a loan”.

Is negative reputation a good idea?

One critique of negative reputation that we sometimes hear is: but isn’t negative reputation a dystopian scheme of “scarlet letters“, and shouldn’t we try our best to do things with positive reputation instead?

Here, while I support the goal of avoiding unlimited negative reputation, I disagree with the idea of avoiding it entirely. Negative reputation is important for many use cases. Uncollateralized lending, which is highly valuable for improving capital efficiency within the blockchain space and outside, clearly benefits from it. Unirep Social shows a proof-of-concept social media platform that combines a high level of anonymity with a privacy-preserving negative reputation system to limit abuse.

Sometimes, negative reputation can be empowering and positive reputation can be exclusionary. An online forum where every unique human gets the right to post until they get too many “strikes” for misbehavior is more egalitarian than a forum that requires some kind of “proof of good character” to be admitted and allowed to speak in the first place. Marginalized people whose lives are mostly “outside the system”, even if they actually are of good character, would have a hard time getting such proofs.

Readers of the strong civil-libertarian persuasion may also want to consider the case of an anonymous reputation system for clients of sex workers: you want to protect privacy, but you also might want a system where if a client mistreats a sex worker, they get a “black mark” that encourages other workers to be more careful or stay away. In this way, negative reputation that’s hard to hide can actually empower the vulnerable and protect safety. The point here is not to defend some specific scheme for negative reputation; rather, it’s to show that there’s very real value that negative reputation unlocks, and a successful system needs to support it somehow.

Negative reputation does not have to be unlimited negative reputation: I would argue that it should always be possible to create a new profile at some cost (perhaps sacrificing a lot or all of your existing positive reputation). There is a balance between too little accountability and too much accountability. But having some technology that makes negative reputation possible in the first place is a prerequisite for unlocking this design space.

Committing to scarcity

Another example of where blockchains are valuable is issuing attestations that have a provably limited quantity. If I want to make an endorsement for someone (eg. one might imagine a company looking for jobs or a government visa program looking at such endorsements), the third party looking at the endorsement would want to know whether I’m careful with endorsements or if I give them off to pretty much whoever is friends with me and asks nicely.

The ideal solution to this problem would be to make endorsements public, so that endorsements become incentive-aligned: if I endorse someone who turns out to do something wrong, everyone can discount my endorsements in the future. But often, we also want to preserve privacy. So instead what I could do is publish hashes of each endorsement on-chain, so that anyone can see how many I have given out.

An even more effective usecase is many-at-a-time issuance: if an artists wants to issue N copies of a “limited-edition” NFT, they could publish on-chain a single hash containing the Merkle root of the NFTs that they are issuing. The single issuance prevents them from issuing more after the fact, and you can publish the number (eg. 100) signifying the quantity limit along with the Merkle root, signifying that only the leftmost 100 Merkle branches are valid.