V God's latest long article: What are the non-financial use cases of blockchain?

Recently, Ethereum founder Vitalik Buterin (V god) published a blog "What are the non-financial use cases of blockchain?" ". V God said that he has always strongly supported the trend of using blockchain for non-financial applications, and people need to stay away from both "blockchain omnipotence" and "blockchain minimalism". He said he sees value in blockchain in many cases, sometimes for really important goals like trust and censorship, sometimes just for convenience.

V God also listed 8 non-financial application scenarios that can use blockchain in the article: user account key change and recovery, modification and revocation of certification, negative reputation, proof of scarcity, public knowledge, and other blockchain applications Program interoperability, open source metrics, data storage. The two non-financial applications he says he is most confident so far are: interoperability with other blockchain applications and account management.

The following is a long blog post by V God, compiled by Odaily Planet Daily:

Recently, there has been an increased interest in non-financial applications of blockchain, which is something I have been very much in favor of. Last month, I co-authored a paper with Puja Ohlhaver and Glen Weyl describing a more detailed vision of what soul-bound tokens (SBTs) could do in a richer ecosystem where these Coins can describe various relationships. This has sparked some discussion as to whether it makes sense to use blockchain in a decentralized identity ecosystem.

From this, we further ask the question: what is the point of using blockchain in non-financial applications? Should we be heading towards a world where, even with decentralized chat apps, every message is processed through an on-chain transaction containing encrypted information? Or, is blockchain only suitable for the financial industry (for example, 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 localized systems?

My own point of view is like blockchain voting (Odaily; Note: V God hints that he is more neutral and objective), neither "blockchain everywhere" nor "blockchain minimalism" ( blockchain maximalist). I see the value of blockchain in many situations, sometimes for really important goals like trust and censorship resistance, but sometimes purely for convenience. This post will attempt to describe blockchain, situations where it may or may not be useful in some ways. Please note that this article is not a complete list and many things are intentionally left out, our goal is to clarify some common categories. ;

1. User account key change and recovery

One of the biggest challenges in cryptographic account systems is the key change problem, which can happen in several ways:

• 「;1;」You are worried that your current key may be lost or stolen, and want to change to a different key;
• ";2;" you want to switch to a different encryption algorithm (e.g. because you fear that quantum computers will appear soon and you want to upgrade to a post-quantum algorithm);
• 「;3;」Your key is lost and you want to regain access to your account;
• ";4;" Your key has been stolen and you want to regain exclusive access to your account (which you don't want a thief to do).

Implementing the first two points is relatively simple because they can be done in a completely autonomous fashion: you control key X, and you want to switch to key Y, so you publish a message signed by X saying "Verify me with Y from now on." ’, everyone accepts that.

Note, however, that even for these relatively simple key-change scenarios, you can't just use cryptography. Consider the following situation:

• You are worried that key A may be stolen, so you sign a message with A saying "I use B now";
• A year later, hackers do steal key A, but they can use A to sign messages saying "I use C now", where C is their own key;

For latecomers who receive two messages at the same time, they only see that A is no longer used, but they don't know which of the two messages "replace A with B" or "replace A with C" has a higher priority class.

This is very similar to the "double spend problem" encountered when designing a decentralized currency, but this time the goal is not Instead of preventing the former owner of the coin from sending it again, it is preventing the former key 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. The blockchain can time-stamp key change messages to determine which came first, B or C.

To solve ";3;" and ";4;" is harder, my own preferred solution is multisig and social recovery wallet. In the event of loss or theft, your friends, family and other contacts can transfer control of your account to a new key. Their involvement may also be required for critical operations such as transferring large amounts of funds or signing important contracts.

"Social recovery" using secret sharing is theoretically possible, but difficult in practice: if you no longer trust some of your contacts, or they want to change their keys, you can't revoke access rights in case of So we're back to the problem - some form of on-chain record is needed.

There is a subtle but important idea in DeSoc's paper: In order to maintain non-transferability, socially restored profiles may actually need to be enforced. That said, even if you sell your account, you can always use social recovery to take back ownership of the account. This would address issues such as drivers with bad credit buying verified accounts on ride-sharing platforms. This is a speculative idea and does not have to be fully realized to reap the other benefits of a blockchain-based identity and reputation system.

Note that this is only a limited use case of blockchain so far: it is perfectly fine to have accounts on-chain but do other things off-chain. This type of hybrid vision has its place; Sign-in With Ethereum is a good simple example of how this can be done in practice.

2. Modify and revoke certification

Alice attends Example College to earn her degree, and she is given a digital certificate of record signed by Example College's key. Unfortunately, six months later, Example College discovered that Alice had plagiarized extensively and revoked her degree. But Alice continues to walk around using the old digital records, claiming to various people and institutions that she has a degree. Even the proof might come with some permissions (for example, logging into the college online forum), Alice might try How do we prevent this?

The approach of "blockchain minimalism" is to make the degree an NFT on the chain, so that Example College can issue an on-chain transaction to revoke the NFT. But this may be a necessary expense: issuances are common, revocations are rare; we don't want Example College to issue transactions unnecessarily and pay for each issuance. Therefore, we can adopt a hybrid solution: make the initial degree an off-chain signed message, and on-chain revocation. This is the method used by OpenCerts.

A completely off-chain solution, advocated by many proponents of off-chain verifiable credentials, is to have Example College run a server where they post a full list of revoked certificates (each certificate can be accompanied by a nonce for increased privacy, A revocation list can be just a list of random numbers).

Running a server is not a huge burden for a university. But for other smaller organizations or individuals, managing "yet another server script" and making sure it stays online can be a significant 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 is better to keep the system decentralized and only use the blockchain - especially now that rollups, sharding (sharding) and other technologies are finally starting to come online, making blockchains cheaper and cheaper.

3. Negative reputation

Another important area where off-chain signatures fall short is “negative reputation” — that is, people or organizations involved in the proofs you make may not want you to see their proofs. I'm using "negative reputation" as a technical term here: the most obvious use case is bad reviews about someone, such as bad reviews or reports of someone's negative behavior in certain contexts; but there are other scenarios where "Negative" proof, which doesn't imply bad behavior - such as taking out a loan that wants to prove that you haven't taken out too many other loans at the same time.

For off-chain claims, you can do positive reputation because showing it makes you more reputable (or do a zero-knowledge proof) to the recipient of the claim; but you can't do negative reputation because people always choose to show Make a positive statement and ignore all other bad claims.

Therefore, writing proofs on-chain can actually solve the above problems. For privacy, we can add encryption and zero-knowledge proofs: a proof can simply be a piece of data recorded on-chain, encrypted with the receiver's public key, and the user can prove that they have no negative reputation by running a zero-knowledge proof, This requires traversing the entire history recorded on-chain. Proofs are on-chain, and the verification process is blockchain-aware, so it's easy to verify that the proof actually traversed the entire history and didn't skip any records. To make this computation feasible, users can use incrementally verifiable computations (such as Halo) to maintain and prove a tree of records, while revealing parts of the tree when needed.

Negative reputation and revocation proofs are in a sense an equivalent problem: you can revoke a proof by adding another proof of negative reputation that says "this other proof is no longer valid", and you can revoke a proof with positive reputation To achieve the revocation of negative reputation: Alice's degree from Example College can be revoked and replaced with a degree certificate that says "Alice obtained a degree from example studies, but she plagiarized a lot".

**Is a negative reputation a good idea? **

One critique of negative reputation that we sometimes hear is: Isn’t negative reputation a dystopian “scarlet letters” binary solution, and shouldn’t we try to do things with positive reputation? (Odaily; Note: The heroine in the scarlet letters novel is punished and needs to wear a scarlet letter "A" symbolizing "adultery" on her chest.)

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. Unsecured lending is extremely valuable for improving capital efficiency in and out of the blockchain space and can clearly benefit 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 everyone has the right to post until they get too much "punished" for inappropriate behavior is more egalitarian than a forum that requires some sort of "proof of good character" to be allowed to speak. Most of the marginalized people who live "outside the system", no matter how good their conduct is, it is difficult to obtain such a certificate.

Readers who are strongly pro-civil libertarians might also consider the case of anonymous reputation systems for sex worker clients: you want privacy, but you might also want a system - if a client abuses a sex worker, others can See and stay away more carefully. In this way, a negative reputation that is difficult to hide can actually empower the vulnerable and keep them safe. The point here is not to defend some specific scheme for negative reputation; rather, it is to show that negative reputation can unlock very real value, and that a successful system needs to support it in some way.

Negative reputation doesn't have to be unlimited negative reputation: I think it should always be possible to create new profiles at some cost (possibly sacrificing most or all of the existing positive reputation). There is a balance between too little accountability and too much accountability, and we need to find that balance. But having some technology that could enable a negative reputation in the first place is a prerequisite to unlocking this design space.

4. Committed to Scarcity (Proof of Scarcity)

Another example of blockchain value is the issuance of a limited number of proofs. If I wanted to endorse someone (for example, one could imagine a company recruiting or a government visa program might look at such an endorsement), a third party viewing the endorsement might wonder if I'm wary of the endorsement, or if it's almost as long as it's my friend doing it. As a polite request, I will endorse them.

The ideal solution to this problem would be to make endorsements public, so that endorsements become aligned with incentives: if the person I endorsed did something wrong, everyone could give me a discount in the future. But many times, we also want to protect privacy. So I can publish the hash of each endorsement on-chain so anyone can see how many endorsements I have issued.

A more efficient use case is to issue multiple at once: if an artist wants to issue N copies of a "limited edition" NFT, they can issue on-chain a single hash containing the Merkle root of their issued NFT. 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.

By publishing a single Merkle root and a maximum count on-chain, you can submit a limited number of proofs. In this example, there are only five possible valid Merkle branches that satisfy the proof check. Astute readers may notice a conceptual similarity to Plasma chains.

5. Public Knowledge

One of the powerful properties of blockchains is that they create public knowledge: if I publish something on the chain, Alice can see it; Alice can see Bob can see it; Charlie can see Alice can see it Until Bob can see it, and so on.

Common knowledge is often important for collaboration. For example, a group of people may want to speak out on an issue, but they will only feel comfortable if enough people are speaking at the same time that they can be safely hidden in the crowd. One possible way to achieve this is for one person to start a "commitment pool" around a particular statement, and invite others to post a hash (privately at first) to signify their agreement. Only if enough people participate within a certain period of time, all participants need to publicly state their position in their next on-chain message.

Such a design could be implemented with a combination of zero-knowledge proofs and a blockchain (could be done without a blockchain, but this would require witness encryption - not currently available; or require trusted hardware, whose security assumptions are seriously questionable) . There is a lot of design space around these ideas, which is not fully explored today, but will grow rapidly as the ecosystem of blockchain and cryptography tools develops further

6. Interoperability with other blockchain applications

This is a simple example: something should be on-chain to better interoperate with other on-chain applications. Human identity proofs as on-chain NFTs, allowing projects to automatically airdrop or grant permissions to accounts with human identity proofs. Putting oracle data on-chain makes it easier for decentralized finance (DeFi) projects to read. In these cases, blockchain does not eliminate the need for trust, although it can accommodate structures that manage trust (such as DAOs). The main value that exists on-chain is simply being co-located with the things you are interacting with, which requires using the blockchain for other reasons.

Of course, you could run oracles off-chain and only import data when you need to read it, but in many cases this would actually be more expensive and introduce unnecessary complexity and cost to developers.

7. Open source indicators

A key goal of the decentralized society paper is to enable the possibility of computing on proof graphs, and a very important metric is to measure decentralization and diversity. For example, a lot of people seem to think that the ideal voting mechanism would allow for diversity, giving more weight to projects that are not only supported by a large number of tokens and even humans, but supported by genuinely diverse viewpoints.

The quadratic funding implemented in Gitcoin Grants also includes some logic that explicitly supports diversity to mitigate attacks. Explicit logic to support diversity to mitigate attacks

Another thing that can make measurement and scoring valuable is reputation systems. This already exists in the ratings in a centralized way, but it can be done in a more decentralized way, making the algorithm transparent and protecting more user privacy at the same time.

In addition to tightly coupled use cases like this (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. When it comes to measuring decentralization, areas that are overly concentrated may need to respond. In these cases, it is inevitable to run computer algorithms on a large number of proofs and commitments, and to perform real important operations on the output.

Instead of trying to abolish quantitative metrics, we should be trying to create better metrics

Kate Sills expresses her skepticism about computing reputation goals, an argument that applies both to public analysis and to individual ZKs proving their reputation (like Unirep Social): “The process of evaluating claims is very subjective and context-dependent. People There will naturally be disagreements about the credibility of others, and trust depends on the context ... (hence) we should be extremely skeptical of all proposals that claim that "computation" can achieve objective results."

In this case, I agree that subjectivity and context need to be taken into account, but I disagree with the statement that avoiding calculations around reputation altogether is the right thing to do. Pure individualized analysis will not go far beyond the "Dunbar number", and any complex society trying to support large-scale cooperation must rely on aggregation and simplification to some extent. (Odaily; Note: Dunbar's number is also known as ";150 Law", which refers to the upper limit of the number of people who can maintain a close interpersonal relationship with a certain person, usually people think it is 150;.)

Having said that, I think an open and participatory proof ecosystem (as opposed to the centralized ecosystem we have today) can achieve the best of both worlds by opening up space for better metrics. Here are some principles that such designs can follow:

Intersubjectivity: For example, reputation should not be a single global rating; instead, it should be a more subjective calculation involving the person or entity being assessed, the observer viewing the rating, and perhaps even other aspects of the local environment.

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 and fewer changes to algorithms.

Openness: The ability to have meaningful input, and to examine others' output by oneself, should be open to anyone, not just a few powerful groups.

If we don't create good aggregation of social data at scale, we risk losing market share to opaque and centralized social credit scoring.

Not all data should be on-chain, but exposing some data in a common-sense way can help improve the readability of the community to itself without creating discrepancies in data access that could be abused for centralized control.

Eight, as data storage

This is a really controversial use case, even though many people embrace other use cases of blockchain. In the blockchain space, there is a general view that blockchains should only be used when there is a real need and cannot be avoided, and that elsewhere we should use other tools.

In a world where transaction fees are very expensive and blockchains are terribly inefficient, this argument makes sense. But in a blockchain with rollups and sharding and transaction fees down to pennies, this idea is less plausible. In such a world, the difference in redundancy between blockchain and non-blockchain decentralized storage might only be a factor of 100.

Even in such a world, it would be unwise to store all data on-chain. But what about small text records? Absolutely. Why? Because the blockchain is actually a very convenient place to store things. I keep a copy of this blog on IPFS. But uploading to IPFS typically takes an hour, and it requires centralized gateways to give users access at speeds approaching website-level latency, and sometimes files disappear and can no longer be viewed. On the other hand, dumping the entire blog on-chain would completely solve this problem. Of course even after sharding the blog is too large to actually dump on-chain, the same principle applies to smaller records,

Some examples of small use cases where data may be stored on-chain include:

Enhanced Secret Sharing: Divide the 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. By publishing additional R parts on-chain (seemingly randomly), and doing N-of-(N+R) secret sharing for the entire set.

ENS optimization. ENS can be made more efficient by combining all records into one hash, publishing only the hash on-chain, and requiring anyone accessing the data to fetch the full data from IPFS. But this adds significant complexity and increases the dependency on another piece of software. Therefore, even if the data length of ENS exceeds; 32; bytes, it will remain on the chain.

Social Metadata - Data associated with your account (e.g. for an Ethereum login) that you wish to make public and very short in length. That's fine for text records, but generally not for larger data, like a profile picture (which might work if the picture happens to be a small SVG file).

Authentication and access rights. Especially when the stored data is less than a few hundred bytes long, 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 cases, the trade-off is not just cost, but also privacy in the extreme case of compromised keys or passwords. Sometimes privacy only matters to a certain extent, and rather than worrying about compromised keys or the occasional loss of privacy from quantum computing, it's better to ensure that data can always be reliably accessed. After all, off-chain data stored in your "data wallet" can also be hacked.

But sometimes, the data is particularly sensitive, and that might just be another argument against putting it on-chain and storing it locally as a second layer of defense. Note, however, that in these cases the need for privacy is an argument not just against blockchains, but against all decentralized storage.

in conclusion

Of the above list, the two use cases I personally feel most confident about right now are "interoperability with other blockchain applications" and "account management". The first is already on-chain, the second is relatively cheap (needs to use the chain once per user, not once per operation), has a clear case for it, and really doesn't have a good non-blockchain-based solution.

"Negative reputation" and "revocation of certification" are also important, although they are still relatively early use cases. You can do a lot with reputation by relying solely on off-chain positive reputation, but I expect the cases for revocation and negative reputation will become clearer over time. I predict that someone will try to do this with a centralized server, but over time it should be clear to all: blockchain is the only way to avoid the hard choice between inconvenience and centralization.

Blockchains as data storage for short text records may be trivial or significant, but I do expect these kinds of uses to at least continue to happen. Blockchain is really handy for low-cost and reliable data retrieval, whether the application has two users or two million users, the data can continue to be retrieved.

Open source metrics are still in a very early conceptual stage, and it remains to be seen how much they can do without being exploited (such as online reviews, social media ratings, etc. are often exploited). And the common knowledge game needs to convince people to accept entirely new workflows for socially important things, so it's certainly an early-stage idea as well.

I'm very unsure of the exact extent of non-financial blockchain usage in these categories, but it's clear that blockchain as an enabling tool in these areas should not be dismissed.