An Overview of Non-Financial Blockchain Applications Favored by Vitalik

Author: Vitalik Buterin

Original Title: 《Decentralized Society: Finding Web3's Soul》

Compiled by: Overnight Porridge, The Way of DeFi

Special thanks to Shrey Jain and Puja Ohlhaver for their extensive feedback and review assistance.

Recently, there has been increasing interest in non-financial blockchain applications. For various reasons, I have strongly supported this trend. Last month, Puja Ohlhaver, Glen Weyl, and I collaborated on a paper that describes a more detailed vision of what can be achieved through a richer soul-bound token ecosystem. This has sparked some discussions, particularly focusing on whether it makes sense to use blockchain in a decentralized identity ecosystem:

1. Kate Sills defended off-chain signature statements;
2. Puja Ohlhaver responded to Kate Sills;
3. Evin McMullen and I debated on-chain vs. off-chain proofs in a podcast event;
4. Kevin Yu wrote a technical overview article that raised questions about on-chain and off-chain issues;
5. Molly White presented a pessimistic case against self-sovereign identity;
6. Shrey Jain summarized a Twitter thread that included the above and many other discussions;

It is worthwhile to narrow the focus and pose a broader question: in general, what is the point of using blockchain in non-financial applications? Should we move towards a world where even decentralized chat applications have every message as an on-chain transaction containing encrypted messages? Or is blockchain only beneficial for finance (for example, because network effects mean that funds have a unique demand for a "global perspective"), while all other applications are better served by centralized or more local systems?

My personal view leans towards moving away from the idea of "blockchain everywhere," just like with blockchain voting, and also away from "blockchain minimalism." I have seen the value of blockchain in many cases, sometimes for truly important goals like "trust" and "censorship resistance," but sometimes purely for convenience. This article will attempt to describe some types of situations where blockchain may be useful, particularly in terms of identity, and where it may be less useful. This article is not a complete list and deliberately omits many things; its purpose is to clarify some common use case categories.

User Account Key Changes and Recovery

One of the biggest challenges in cryptographic account systems is the key change issue. This can occur in several scenarios:

1. You are concerned that your current key may be lost or stolen, so you want to switch to another key;
2. You want to switch to a different cryptographic algorithm (for example, because you are worried that quantum computers will soon emerge, and you want to upgrade to post-quantum cryptographic algorithms);
3. Your key is lost, and you want to regain access to your account;
4. Your key is stolen, and you want to regain exclusive access to your account (you do not want the thief to have access as well);

[1] and [2] are relatively simple because they can be done in a fully autonomous way: you control key X, you want to switch to key Y, so you publish a message signed with X that says "from now on verify me with Y," and then everyone accepts this.

But note that even for these simpler key change scenarios, you cannot rely solely on cryptography. Consider the following sequence of events:

1. You are concerned that key A may be stolen, so you sign a message saying "I am now using B";
2. A year later, a hacker indeed steals key A and uses key A to sign a message saying "I am now using C," where C is the hacker's own key;

From the perspective of someone who later receives these two messages, they see that A is no longer in use, but they do not know which has higher priority: "A replaced with B" or "A replaced with C."

This is akin to the well-known double-spending problem encountered when designing decentralized currencies, except the goal here is not to prevent previous token holders from sending it again, but to prevent previously controlled account keys from changing the keys. Just like creating decentralized currency, managing accounts in a decentralized way also requires something like blockchain. Blockchain can timestamp key change messages, providing common knowledge about whether B or C appeared first.

[3] and [4] are more difficult. Generally, my preferred solution is "multi-signature" and "social recovery wallets," where if your account is lost or stolen, a group of friends, family, and other contacts can transfer control of your account to a new key. For critical operations (such as transferring large amounts of funds or signing an important contract), the involvement of that group may also be required.

And this also requires blockchain. Social recovery using secret sharing techniques is possible, but it is practically more difficult: if you no longer trust some of your contacts, or if they want to change their keys, you cannot revoke access without changing the keys. So we are back to requiring some form of on-chain record.

A subtle but important idea in the DeSoc (Decentralized Society) paper is that to maintain non-transferability, social recovery of profiles (or "community recovery") may actually need to be enforced. That is, even if you sell your account, you can still use community recovery to reclaim it at any time. This would address some issues, such as an unknown driver purchasing a verified account on a ride-sharing platform. That said, this is a speculative idea that does not need to be fully implemented to gain other benefits of a blockchain-based identity and reputation system.

Note that, as written here, this is just a limited use case for blockchain: having accounts on-chain while doing everything else off-chain is perfectly fine. There is a place for this hybrid vision, and using Ethereum login is a good simple example of how to achieve this in practice.

Modification and Revocation of Proofs

Alice attended XX College and obtained an XX research degree, for which she received a digital record with a key signature from XX College. Unfortunately, six months later, XX College discovered that Alice had committed significant plagiarism and revoked her degree. But Alice continues to use her old digital record and claims to various people and institutions that she holds this degree. Potentially, the proof could even carry some privileges (for example, the right to log into the college's online forum), and Alice might also attempt to access it improperly. How do we prevent this from happening?

The "blockchain minimalism" approach would be to make the degree an on-chain NFT, so that XX College can issue an on-chain transaction to revoke this NFT. But this approach is expensive and perhaps unnecessary (issuance is common, but revocation is rare; if it is not needed, we do not want to require XX College to pay for issuance transactions). So we can use a hybrid solution: make the initial degree an off-chain signed message and revoke it on-chain, which is the method used by OpenCerts‌.

A completely off-chain solution, also advocated by many off-chain verifiable credential supporters, is for XX College to run a server where they publish a complete list of revocations (to improve privacy, each proof could be accompanied by a nonce, and the revocation list could simply be a list of nonces).

For a university, running a server is not a significant burden. But for any smaller organization or individual, managing "another server script" and ensuring it stays online is a huge burden for IT personnel. If we tell people to "just use servers" out of fear of blockchain, the likely outcome is that everyone will outsource the task to a centralized vendor. It is better to keep the system decentralized and use blockchain, especially now that rollups, sharding, and other technologies are finally coming online, making the costs of blockchain cheaper and cheaper.

Negative Reputation

Another important area where off-chain signatures are insufficient is negative reputation, i.e., the individual or organization you are certifying may not want you to see the relevant proof. I use the term "negative reputation" here as a technical term: the most obvious motivation use case is to prove someone's bad behavior, such as poor reviews or reports of someone abusing behavior in certain situations, but there are also use cases where "negative" proof does not imply wrongdoing, such as applying for a loan and wanting to prove that you have not simultaneously applied for too many other loans.

For off-chain statements, you can gain positive reputation because making the statement's recipient look more credible (or providing ZK proof) aligns with their interests, but you cannot gain negative reputation because someone can always choose to only display statements that make them look good while ignoring all other statements.

Here, authenticating on-chain can indeed solve the problem. To protect privacy, we can add encryption and zero-knowledge proofs: the proof can be an on-chain record, with data encrypted to the recipient's public key, and the user can prove the lack of negative reputation by running a zero-knowledge proof that traverses the entire history of on-chain records. The on-chain proof and the blockchain verification process can easily verify that the proof indeed traversed the entire history and did not skip any records. To make this computation feasible, users can use incrementally verifiable computation‌ (like Halo) to maintain and prove the encrypted record tree, then display certain parts of the tree when needed.

Negative reputation and proof revocation are, in a sense, equivalent problems: you can revoke a proof by adding another negative reputation proof and saying "the other proof no longer matters," and you can implement negative reputation revocation by bearing positive reputation: Alice's degree from XX College can be revoked, and the replacement degree is "Alice obtained an XX research degree, but she borrowed the work of others."

Is Negative Reputation a Good Idea?

We sometimes hear a criticism of negative reputation: isn't negative reputation a dystopian "scarlet letter" scheme? Shouldn't we strive to do things with positive reputation instead?

Here, while I support the goal of avoiding infinite negative reputation, I do not agree with the idea of completely avoiding negative reputation. Negative reputation is important for many use cases. Whether in the blockchain space or unrelated fields, "unsecured lending" is very valuable for improving capital efficiency, which clearly benefits from negative reputation. Unirep Social‌ showcases a proof-of-concept social media platform that combines high anonymity with a privacy-preserving negative reputation system to limit abusive behavior.

Sometimes, negative reputation can enhance power, while positive reputation can be exclusive. For example, in an online forum where every unique person has the right to post until they receive too many "strikes" for misconduct, this is more egalitarian than a forum that requires some form of "good character proof" to be accepted and allowed to speak. And those marginalized groups living "outside the system," even if they are actually well-behaved, find it difficult to obtain such proof.

Some may also consider the case of an anonymous reputation system for sex worker clients: you want to protect privacy, but you may also want a system where if clients abuse sex workers, they receive a "black mark," which can alert other workers to be more cautious or avoid those clients. In this way, undeniable negative reputation can actually empower vulnerable groups to protect their safety. The point here is not to defend specific plans for negative reputation; rather, it is to indicate the real value that negative reputation releases, and a successful system needs to support it in some way.

Negative reputation does not have to be infinite negative reputation: what I mean is that it is always possible to create a new profile at a certain cost (potentially sacrificing much or all existing positive reputation), and there exists a balance between too little accountability and too much accountability. But first, having some technology that enables negative reputation is a prerequisite for opening up this design space.

Commitment to Scarcity

Another example of the value of blockchain is issuing a limited number of proofs. If I want to endorse someone (for example, someone might imagine a company looking for a job, or a government visa program reviewing such endorsements), a third party looking at the endorsement would want to know if I am cautious about the endorsement.

The ideal solution to this problem is to make endorsements public, aligning the endorsement with motivations: if the person I endorsed ultimately proves to have done wrong, then everyone can discount my endorsement in the future. But generally, we also want to protect privacy. Therefore, what I can do is publish the hash of each endorsement on-chain, so anyone can see how many I have given.

A more effective use case is one-time many-at-a-time issuance: if an artist wants to issue N "limited edition" NFTs, they can publish a hash of the Merkle root containing the NFTs they are issuing on-chain. One-time issuance can prevent them from issuing more NFTs afterward, and you can publish a number representing the limit (for example, 100) along with the Merkle root, indicating that only the leftmost 100 Merkle branches are valid.

*By publishing a single Merkle root and a maximum count on-chain, you can submit a limited number of proofs. In this example, only five possible valid Merkle branches can satisfy the proof check. The astute reader may notice that this conceptually resembles *Plasma chains‌.

Common Knowledge

A powerful feature of blockchains is that they create common knowledge: if I publish something on-chain, then Alice can see it, Alice knows that Bob can see it, Charlie knows that Alice knows Bob can see it, and so on.

Common knowledge is often crucial for coordination; for example, a group of people may want to express opinions on an issue, but they will only feel comfortable doing so if they have enough people expressing opinions simultaneously and their numbers are secure. One possible approach is to have one person start a "commitment pool" around a specific statement and invite others to publish hashes indicating their agreement (initially privately). Only if enough people participate over a period will all participants be required to publicly disclose their next on-chain message to indicate their position.

Such a design can be accomplished through a combination of zero-knowledge proofs and blockchain (this can be done without blockchain, but requires witness encryption‌ (currently unavailable) or requires trusted hardware (which has serious security assumption issues)). There is a large design space around such ideas that has not yet been fully developed, but as the ecosystem around blockchain and cryptographic tools further develops, it will be easy to start growing.

Interoperability with Other Blockchain Applications

This is simple: some things should be on-chain to better interoperate with other applications on-chain. Proof of humanity as an on-chain NFT makes it easier for projects to implement automatic airdrops or grant governance rights to accounts with proof of humanity records. On-chain oracle data makes it easier for DeFi projects to read. In all these cases, blockchain does not eliminate the need for trust, although it can accommodate structures like DAOs that manage trust. However, the primary value provided by being on-chain is simply being in the same place as what you are interacting with, for other reasons that require blockchain.

Of course, you could also run an off-chain oracle and only import data when it needs to be read, but in many cases, this would actually be more expensive and unnecessarily complicate things for developers.

Open Source Metrics

A key goal of the Decentralized Society paper is that proofs should be computable. A very important question is how to measure decentralization and diversity. For example, many people seem to agree that an ideal voting mechanism would somehow take diversity into account, giving greater weight not only to projects that receive the most coins or the most support from people but also to projects that receive support from the most different perspectives.

The quadratic funding implemented in Gitcoin Grants‌ also includes some explicit logic favoring diversity to mitigate attacks.

Another area where measuring and scoring is valuable is reputation systems, which already exist in a centralized form of ratings, but can be done in a more decentralized way where the algorithms are transparent while preserving more user privacy.

In addition to tightly coupled use cases like trying to measure the degree of connection between a group of people and directly inputting it into a mechanism, there are broader use cases to help communities understand themselves. In the case of measuring decentralization, this could be a question of identifying areas with excessive concentration that may require a response. In all these cases, running computerized algorithms over a large number of proofs and commitments and doing something truly significant with the output will be inevitable.

We should not try to abolish quantitative metrics, but rather strive to create better metrics.

Kate Sills expressed skepticism about the goal of calculating based on reputation, a point that applies to both public analysis and personal ZK proofs of their reputation (as in Unirep Social):

"The process of evaluating statements is highly subjective and context-dependent. People naturally have differing opinions on the credibility of others, and trust depends on the environment… [For this reason] we should be extremely skeptical of any proposal to 'compute' statements for objective results."

In this case, I agree with the importance of subjectivity and context, but I do not agree with the broader claim that completely avoiding calculations around reputation is the correct goal. The scale of purely personalized analysis will not far exceed Dunbar's number, and any complex society attempting to support large-scale cooperation must rely on aggregation and simplification to some extent.

That said, I believe an open-participation proof ecosystem (as opposed to our current centralized proof ecosystem) can allow us to have the best of both worlds by opening up space for better metrics. Here are some principles that such designs could follow:

1. Inter-subjectivity: For example, reputation should not be a single global score; instead, it should be a more subjective calculation that involves the person or entity being assessed, as well as the audience viewing the score, and possibly other aspects of the local environment.
2. Credible neutrality: The scheme should clearly not leave room for powerful elites to manipulate it for their own benefit continuously. Some possible ways to achieve this are maximum transparency and infrequent changes to the algorithms.
3. Openness: The ability to make meaningful inputs and audit others' outputs by running checks should be open to anyone, not just a few powerful groups.

If we do not create good large-scale social data aggregators, we risk handing market share over to opaque and centralized social credit scoring systems.

Not all data should be on-chain, but publicly disclosing some data in a way that promotes common knowledge helps improve the community's own readability without creating a potential disparity in data access that could be abused for centralized control.

As Data Storage

This is a genuinely controversial use case, even among those who accept most other use cases. There is a common view in the blockchain space that blockchains should only be used when truly necessary and unavoidable, and for anywhere else, we should use other tools.

In a world where transaction fees are very expensive and blockchain efficiency is extremely low, this attitude makes sense. But after blockchain implements rollup and sharding technologies (where transaction fees can be reduced to a few cents), this view becomes less meaningful, and the redundancy difference between blockchain and non-blockchain decentralized storage may only be 100 times.

Even in such a world, it does not make sense to store all data on-chain. But what about small text records? Absolutely necessary, why? Because blockchain is a very practical place to store things. I keep a copy of this blog post on IPFS, but uploading to IPFS usually takes an hour, it requires a centralized gateway for users to access it at near website latency levels, and sometimes files get lost and are no longer visible. On the other hand, dumping the entire blog onto the chain would completely solve this problem. Of course, the blog is too large to actually dump on-chain, even after implementing sharding, but the same principle applies to smaller records.

Some small examples of when it might be the right decision to store data on-chain include:

1. Enhanced secret sharing: Splitting your password into N pieces, where any M = N-R pieces can be used to recover the password, but you can choose the contents of all N pieces. For example, these pieces could all be hashes of the password, secrets generated by other tools, or answers to security questions. This is accomplished by publishing an additional R pieces on-chain (which appear random) and performing N-of-(N+R) secret sharing over the entire set.
2. ENS optimization. By combining all records into a hash, only publishing the hash on-chain, and requiring anyone accessing the data to retrieve the complete data from IPFS, the efficiency of ENS can be improved. But this significantly increases complexity and adds another software dependency. Therefore, even if the data length exceeds 32 bytes, ENS can still store data on-chain.
3. Social metadata. Data connected to your account (for example, for Ethereum login purposes) that you want to make public and is very short in length. For larger data (like avatar images), this is usually not correct (although if the image happens to be a small SVG file, then it might be!), but this is indeed the case for text records.
4. Proofs and access rights. Especially if the data to be stored is less than a few hundred bytes, storing data on-chain may be more convenient than putting a hash on-chain and storing the data off-chain.

In many such cases, the trade-off is not just cost, but also privacy in edge cases where those keys or cryptography are compromised. Sometimes, privacy is just a little important (occasionally lost due to key leaks or distant quantum computing specters), which is not as significant compared to the high certainty that data will remain accessible. After all, off-chain data stored in a "data wallet" can also be hacked.

But sometimes, the data is particularly sensitive, which may be another argument against putting it on-chain and storing it locally as a second layer of defense. But note that in these cases, the privacy need is not only a reason against blockchain but also a reason against all decentralized storage.

Conclusion

Among the use cases listed above, the two I am personally most confident in so far are interoperability with other blockchain applications and account management. The former is already on-chain, while the latter will be relatively cheaper (each user only needs to interact with the chain once rather than once for each operation), and the situation is clear, with indeed no good non-blockchain-based solutions.

Negative reputation and revocation are also important, although they remain relatively early use cases. By relying solely on off-chain positive reputation, we can do a lot in terms of reputation, but I expect that over time, use cases for revocation and negative reputation will become more apparent. I expect there will be attempts to use centralized servers to achieve this, but over time, people should clearly see that blockchain is the only way to avoid making difficult choices between inconvenience and centralization.

The data storage use case for blockchain as short text records may be trivial or significant, but I do hope at least some of such uses will continue to occur. Blockchain is indeed very convenient for cheap and reliable data retrieval, whether the application has 2 users or 2 million users, it can continue to retrieve data. Open source metrics is still a very early idea, and it still needs to see how much can be done and made public without being exploited (for example, online reviews, social media, etc., have been exploited). The common knowledge game requires persuading people to accept a brand new workflow for socially important matters, so this is certainly an early idea.

I am largely uncertain about how meaningful the level of non-financial blockchain usage in these categories is, but it is clear that blockchain as a supporting tool in these areas should not be overlooked.