Recently, there has been growing interest in using blockchain for more than just financial applications. This is a trend that I have always strongly supported, for various reasons. Last month, Puja Ohlhaver, Glen Weyl, and I co-authored a paper that described a more detailed vision of what could be done with a richer ecosystem of soul-bound tokens, and claimed to describe the various relationships. This sparked some discussion, specifically focusing on whether it makes sense to use blockchain in a decentralized identity ecosystem:
- Kate Sills asserts off-chain signature claim
- Puja Ohlhaver responds to Kate Sills
- Evin McMullen and myself have a podcast debating on-chain vs off-chain proofs
- Kevin Yu wrote a technical overview, asking questions about on-chain vs. off-chain
- Molly White Makes a Gloomy Case Against Self-Sovereign Identity
- Shrey Jain made a meta thread containing the above and many other Twitter discussions
It's worth narrowing down and asking a broader question: What's the point of using blockchain in non-financial applications in general? Should we be moving towards a world where even decentralized chat apps work by having every message be an on-chain transaction containing an encrypted message? Or, are blockchains only good for finance (e.g. because network effects mean that currencies have a unique need for a "global view"), while all other applications are best done using centralized or more local systems?
My personal opinion, like blockchain voting, is as far from a "blockchain-everywhere" perspective as it is from "blockchain minimalism". I see the value of blockchain in many contexts, sometimes for really important goals like trust and censorship resistance, but sometimes purely for convenience. This post will attempt to describe some of the 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 many things are intentionally left out. The purpose is to clarify some common categories.
User Account Key Change and Restoration
One of the biggest challenges in encrypted account systems is the key change problem. This can happen in several situations:
- You are concerned that your current key may be lost or stolen and want to switch to a different key
- You want to switch to a different encryption algorithm (e.g. because you are concerned that quantum computers are coming soon and you want to upgrade to post-quantum)
- Your key has been lost and you would like to regain access to your account
- Your key has been stolen and you want to regain exclusive access to your account (and you don't want the thief to be able to)
[1] and [2] are relatively simple because they can be done in a completely autonomous way: you control key X, you want to switch to key Y, so you publish a message signed by X saying "Authenticate me with Y from now on" and everyone accepts that.
But note that even for these simpler key changing scenarios, you can't just use cryptography. Consider the following sequence of events:
- You are concerned that key A might be stolen, so you sign a message with A that says "I use B now"
- A year later, the hacker did steal Key A. They signed a message saying A with "I use C now" where C is their own key
From the perspective of whoever comes in later and just received those 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 a higher priority.
This is equivalent to the famous double-spending problem when designing decentralized currencies, except the goal is not to prevent previous coin owners from being able to send it again, the goal here is to prevent the key previously controlling the 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 key change messages, providing common knowledge about whether B or C came first.
[3] and [4] are harder. In general, my own preferred solutions are multisig and social recovery wallets, a group of friends, family and other contacts that can transfer control of your account to new keys if lost or stolen. The group's involvement may also be required for critical operations (for example, transferring large amounts of money, or signing important contracts).
But it also requires blockchain. Social recovery using secret sharing is possible, but more difficult in practice: if you no longer trust some of your contacts, or if they want to change their keys, you cannot to revoke access. So we're back to requiring some form of on-chain recording.
A subtle but important idea in DeSoc's paper is that social recovery (or "community recovery") of profiles may actually need to be enforced in order to maintain non- transferability . That said, even if you sell your account, you can always use community recovery to get it back. This will address issues such as not really reputable drivers purchasing verified accounts on ride-sharing platforms. That said, it's a speculative idea that doesn't have to be fully implemented to reap the other benefits of a blockchain-based identity and reputation system.
Note that this is a limited blockchain use case so far: it's perfectly fine to have accounts on-chain, but do everything else off-chain. These hybrid visions all have a place. Login with Ethereum is a nice simple example of how this can be done in practice.
Amendment and revocation certificate
Alice enters Example Academy and earns a degree in Example Studies. She obtained a digital record to prove this, signed with Example College's key. Unfortunately, six months later, Example College discovered that Alice had plagiarized extensively and revoked her degree. But Alice continues to use her old digital records to go around and claim to various people and institutions that she has a degree. Potentially, the certificate could even carry permissions —for example, the right to log into the college's online forum—and Alice might try to access it inappropriately. How can we prevent this from happening?
The "blockchain minimalist" approach is 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 unnecessarily expensive: issuances are common, revocations are rare, and we don't want to require Example College to issue transactions and pay for each issuance if they don't have to. Therefore, we can adopt a hybrid solution: make the initial degree an off-chain signed message, and do the revocation on-chain. This is the method used by OpenCerts.
A fully off-chain solution, and one advocated by many proponents of off-chain verifiable credentials, is for Example College to run a server where they publish their complete list of revocations (for improved privacy, each proof can be accompanied by a The nonce and revocation list can be just a list of nonces).
Running servers is not a huge burden for a university. But for any smaller organization or individual, managing "yet another server script" and making sure it stays online is a huge burden on the IT staff. If we tell people to "just use servers" out of blockchain fears, the likely outcome is that everyone outsources tasks to a centralized provider. It’s best to keep the system decentralized and only use the blockchain — especially now that rollups, sharding, and other technologies are finally starting to come online to make blockchains cheaper and cheaper.
negative reputation
Another important area where off-chain signatures are not enough is negative reputation - that is, the person or organization you are certifying against may not want you to see their certifying. I'm using "negative reputation" as the technical term here: the most obvious incentive use case is proof of saying something bad about someone, such as a bad review or a report of someone abusing in some circumstances, but there are also use cases for "negative" proof and Doesn't imply bad behavior - eg, taking out a loan and wanting to prove that you haven't taken out too many other loans at the same time.
With off-chain claims, you can have positive reputation because it's in the claim recipient's interest to show that the claim looks more reputable (or ZK-prove it), but you can't have negative reputation because someone can always choose to just Show the declarations that make them look good, and ignore all others.
Here, doing proofs on-chain does the trick. For privacy, we can add encryption and zero-knowledge proofs: proofs can simply be on-chain records where data is encrypted to the recipient's public key, and users can prove the lack of negative reputation by running a zero-knowledge proof. The entire history recorded on-chain. On-chain proofs and a blockchain-aware verification process make it easy to verify that proofs have indeed traversed the entire history and no records have been skipped. To make this computation feasible, users can use incrementally verifiable computations (such as Halo) to maintain and prove a tree of records encrypted against them, and then reveal parts of the tree when needed.
Negative reputation and revocation proofs are in a sense equivalent problems: you can revoke a proof by adding another negative reputation proof, saying "this other proof doesn't matter anymore", and you can achieve negative reputation by piggybacking on positive reputation : Alice's degree at Example College could be revoked and replaced with "Alice got a degree in Example Studies, but she took out a loan".
Is a negative reputation a good idea?
The critique we sometimes hear of negative reputations is: but isn’t a negative reputation the Scarlet Letter ’s dystopian project, and shouldn’t we do our best to do things with a positive reputation?
Here, while I support the goal of avoiding infinite negative reputation, I disagree with the idea of avoiding it entirely. Negative reputation is important for many use cases. Unsecured lending, which is very valuable for improving capital efficiency in and out of the blockchain space, is clearly benefiting from it. Unirep Social demonstrated a proof-of-concept social media platform that combines high levels of anonymity with a privacy-preserving negative reputation system to limit abuse.
Sometimes a negative reputation can be empowering, while a positive reputation can be exclusive. An online forum where every unique person has the right to post until they get too many "strikes" for inappropriate behavior is more egalitarian than a forum that requires some sort of "proof of good character" to be recognized and allowed to speak in the first place . Marginalized people who live mostly "outside the system", even if they are actually good characters, can hardly get such a certificate.
Readers of strong civil libertarian persuasion might also want to consider the case for a sex worker client-anonymous reputation system: you want privacy, but you might also want a system where if a client mistreats a sex worker, they get incentives for other workers to be more Be careful or stay away from "black marks". In this way, a hard-to-disguise negative reputation can actually empower the vulnerable and keep them safe. The point here is not to justify some particular negative reputation scheme; rather, it is to show that negative reputation can unlock very real value, and a successful system needs to support it in some way .
Negative reputation doesn't have to be infinite negative reputation: I think it should always be possible to create new profiles at some cost (possibly at the expense of many or all existing positive reputations). There is a balance between having too little responsibility and having too much responsibility. But having some of the technologies that enable negative reputations in the first place is a prerequisite for opening up this design space.
Committed to scarcity
Another example of blockchain's value is the issuance of a finite number of provable proofs. If I want to do an endorsement for someone (for example, one might imagine a company looking for a job or a government visa program looking for such an endorsement), a third party looking at the endorsement will want to know if I am cautious about the endorsement or If I give them to someone who is almost friends with me and asks well.
The ideal solution to this problem would be to make the endorsement public, so that the endorsement would align with the incentive: if the person I endorsed did something wrong, then everyone in the future could discount my endorsement. But often, we also want privacy. So what I can do is publish the hash of each endorsement on-chain so anyone can see how much I'm giving.
A more efficient use case is multiple issuances at once: if an artist wants to issue N copies of a "limited edition" NFT, they can publish on-chain a single hash containing the Merkle root of the NFT they are issuing. A single issue prevents them from issuing more after the fact, and you can issue a number representing a limit (eg 100) with the Merkle root, meaning only the leftmost 100 Merkle branches are valid.
similarities in concept.
common sense
One of the powerful properties of blockchains is that they create common knowledge : if I publish something on the chain, then Alice can see it, Alice can see Bob can see it, Charlie can see Alice can see Bob can see it, and so on.
Common sense is often important for coordination. For example, a group of people might want to voice an opinion on an issue, but only feel comfortable doing so if they have enough people voiced at the same time to keep the number safe. One possible approach is for one person to start a "commitment pool" around a particular statement, and invite others to post hashes (privately at first) that signify their agreement. Only if enough people participate over a period of time, all participants need to have their next on-chain message publicly reveal their location.
A design like this can be done with a combination of zero-knowledge proofs and a blockchain (it can be done without a blockchain, but this requires witness encryption, which is not currently available, or has serious issues with trusted hardware security assumptions). There is a large design space around these ideas, which are underexploited today but easy to start developing once the ecosystem around blockchain and cryptographic tools develops further.
Interoperability with other blockchain applications
It's simple: some things should be on-chain to better interoperate with other on-chain applications. Proof of Humanity as an on-chain NFT makes it easier for projects to automate airdrops or grant governance rights to accounts with Proof of Humanity. On-chain oracle data makes defi projects easier to read. In all of these cases, the blockchain does not eliminate the need for trust, although it can accommodate structures such as DAOs that manage trust. However, the main value provided on-chain is simply being in the same place as the things you are interacting with, blockchains are needed for other reasons .
Of course, you could run the oracle off-chain and require data to be imported only when it needs to be read, but in many cases this would actually be more expensive and introduce unnecessary complexity and cost to developers .
open source metrics
A key goal of the decentralized society paper is that it should be possible to compute proof graphs. A very important one is to measure decentralization and diversity. For example, many seem to agree that an ideal voting mechanism would somehow keep diversity in mind, awarding projects not only backed by the greatest number of coins or even humans , but by the greatest number of genuinely diverse viewpoints .
|
|
|
The quadratic funding implemented in Gitcoin Grants also includes some explicit logic in favor of diversity to mitigate attacks.
Another place where measurements and scores are naturally valuable is in the reputation system. This already exists in a centralized form with ratings, but it can be done in a more decentralized fashion where the algorithm is transparent while preserving more user privacy.
Beyond tightly coupled use cases like this one (trying to measure how connected someone is and feeding that directly into the mechanism), there are broader use cases for helping a community understand itself. In measuring decentralization, this may be a matter of identifying areas of excessive concentration, which may require a response. In all of these cases, it will be inevitable to run computerized algorithms on massive proofs and commitments and do really important things with the output.
Instead of trying to abolish quantitative metrics, we should strive to make better metrics
Kate Sills expresses her skepticism about the goal of computing based on reputation, an argument that applies to both public analytics and individual ZKs proving their reputation (as in Unirep Social):
The process of evaluating a claim is highly subjective and context-dependent. People naturally disagree about the trustworthiness of others, and trust depends on context... [So] we should be extremely skeptical of any proposal to "calculate" claims to obtain objective results.
In this case, I agree with the importance of subjectivity and context, but I disagree with the broader claim that avoiding calculations around reputation altogether is the right goal. Purely individualized analysis does not go beyond Dunbar's numbers, and any complex society attempting to support large-scale cooperation must rely to some extent on aggregation and simplification.
That said, I think an open and participatory proof-of-concept ecosystem (as opposed to the centralized ecosystem we have today) can give us the best of both worlds by opening up space for better metrics. Here are some principles that such designs can follow:
- Intersubjectivity: eg. Reputation should not be a single global score; rather, it should be a more subjective calculation involving the person or entity being assessed, the audience viewing the score, and possibly even other aspects of the local context.
- Credible neutrality: The program clearly should not leave room for powerful elites to constantly manipulate it for their own benefit. Some possible ways to achieve this are maximum transparency of the algorithm and infrequent changes.
- Openness: The ability to make meaningful input, and to review the output of others by running checks yourself, should be open to anyone, not just a few powerful groups.
If we don't create good large-scale social data aggregates, then we risk losing market share to opaque and centralized social credit scores.
Not all data should be on-chain, but exposing some data in a common-sense manner can help make it more legible to the community without creating discrepancies in data access that could be abused for centralized control.
as data storage
This is a really controversial use case, even among those who accept most other use cases. There is a common view in the blockchain space that blockchain should only be used when it is really needed and unavoidable, and everywhere else we should use other tools.
This attitude makes sense in a world where transaction fees are very expensive and blockchains are extremely inefficient. But in a world where blockchains have rollups and shards and transaction fees have dropped to pennies, that doesn't make sense, and the difference in redundancy between blockchain and non-blockchain decentralized storage may only be 100 times.
Even in such a world, it would not make sense to store all data on-chain. But small text records? Absolutely. Why? Because the blockchain is just a very convenient place to store things. I maintain a copy of this blog on IPFS. But uploading to IPFS often takes an hour, it requires a centralized gateway for users to access it with anything approaching the latency level of a website, and sometimes files get lost and are no longer visible. On the other hand, dumping the entire blog on-chain would completely solve this problem. Of course, blogs are too large to actually dump on-chain, even post-sharding, but the same principle applies to smaller records.
Some small examples where putting data on-chain just to store it might be the right decision include:
- Enhanced Secret Sharing: Divide your password into N parts, where any M = NR part can recover the password, but you can choose the contents of all N parts. For example, these pieces could be hashes of passwords, secrets generated by other tools, or answers to security questions. R This is done by publishing additional N on-chain for secret sharing across the set. (N+R)
- ENS optimization. ENS can be more efficient by combining all records into one hash, only publishing the hash on-chain, and requiring anyone who accesses the data to fetch the full data from IPFS. But this adds significant complexity and adds another software dependency. Therefore, ENS keeps data on-chain even if it exceeds 32 bytes.
- Social Metadata - Data connected to your account (for example, for the purpose of logging in with Ethereum) Data that you wish to make public and very short in length. This isn't usually true for larger data like profile pictures (although it might be if the picture happens to be a small SVG file!), but is true for text records.
- Proof and access rights. Especially if the length of data to be stored is less than a few hundred bytes, it may be more convenient to store the data on-chain than to put the hash on-chain and the data off-chain.
In many of these cases, the trade-off is not only cost, but also privacy at the edge of key or cryptography breaches. Sometimes privacy is only a little bit important, and the occasional loss of privacy due to a leaked key or the distant specter of quantum computing revealing everything in 30 years is not as important as a high degree of certainty that the data will remain accessible. After all, off-chain data stored in “data wallets” can also be hacked.
But sometimes, the data is particularly sensitive, which could be another argument against putting data on-chain and storing it locally as a second layer of defense. Note, however, that in these cases the need for privacy is not only against blockchains, but against all decentralized storage.
in conclusion
Of the list above, the two I personally feel most confident in so far are interoperability with other blockchain applications and account management. The first is already on-chain, the second is relatively cheap (requires using the chain once per user, not once per action), its case is clear, and there really isn't a good non-blockchain-based solution plan.
Negative reputation and revocation are also important, although they are still relatively early use cases. A lot can be done with reputation just by relying on positive reputation off-chain, but I hope over time the situation with regard to revocation and negative reputation will become clearer. I anticipate that there will be attempts to do this with centralized servers, but over time it should become clear that blockchain is the only way to avoid the difficult choice between inconvenience and centralization.
Blockchains as data storage for short text records may be trivial or important, but I do hope that at least some of these uses will continue to happen. Blockchain is really handy for cheap and reliable data retrieval, whether the application has two users or 2 million users, the data can continue to be retrieved. Open source metrics are still a very early idea, and it remains to be seen how much can be done and opened up without being exploited (e.g. online reviews, social media karma, etc. are exploited all the time). The common sense game needs to convince people to accept new Workflows for things of social importance, so of course it was an early idea as well.
I'm largely unsure how relevant the level of non-financial blockchain usage in these categories really is, but it seems clear that blockchain should not be ignored as an enabling tool in these areas.