V God: In addition to finance, what other scenarios are blockchains suitable for?
This article comes from Vitalik Buterin, compiled by Odaily translator Katie Koo.
This article comes from
, compiled by Odaily translator Katie Koo.
This begs the question - what use of blockchain outside of finance makes sense? Should we expect decentralized chat apps where every message is an on-chain transaction containing an encrypted message? Or is blockchain only good for finance, while all other applications are better suited for centralized or local systems?
I am not a proponent of blockchain maximization or minimization arguments. Blockchains are sometimes used to solve pain points, such as trust and censorship resistance, and sometimes purely for convenience. This article will attempt to describe some potential use cases for blockchains (especially in the context of identity binding), and examples where blockchains are not applicable.
secondary title
User Account Key Change and Restoration
One of the biggest challenges in encrypted account systems is the key change problem. It happens in four situations:
Worried that the current key may be lost or stolen, and want to change to a different key;
Want to switch to a different encryption algorithm (such as fears that quantum computers will appear soon);
Lost the key and want to reopen the account;
The key has been stolen and you want to regain exclusive access to the account (don't want the hacker to be able to do the same).
The first two points are relatively simple because they can be done in a completely autonomous way: you control key X, want to switch to key Y, publish a message signed with X - "verify me with Y from now on", everyone All agree.
Note, however, that even for these simpler key-change scenarios, cryptography alone cannot be used. Consider the following sequence:
Worried about key A being stolen, so you sign a message with A - "I'm using B now";
A year later, a hacker actually steals key A. They sign a message - "I'm using C now", where C is their own key.
From the perspective of latecomers, they have just received these two messages and see that A is no longer used, but they don't know whether "replace A with B" or "replace A with C" is a higher priority.
This is equivalent to the famous "double spend problem" in decentralized currency design, except that the goal here is not to prevent the previous owner of the coin from sending it again, but to prevent the key of the previous controlling account from being able to change the key. Just like creating a decentralized currency, account management in a decentralized manner requires a blockchain. A blockchain can timestamp key change messages, providing a hint as to whether B or C came first.
The last two points are more difficult. My preferred solutions are multisig and social recovery wallets, where other contacts can transfer control of your account to a new key if your account is lost or stolen. Contacts can also be requested for critical operations such as transferring large amounts of money, or entering into important contracts.
This also requires blockchain technology. Restoring social using password 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 have no way to revoke access without changing their own keys . So we're back to needing some form of on-chain record.
Note that this is only a limited use case of blockchain so far: it is perfectly fine to have accounts on-chain but do everything else off-chain. This vision currently has landing scenarios, such as Sign-in With Ethereum.
(Odaily Note: "Sign-In with Ethereum" is a set of technical specifications for logging in to third-party web applications through Ethereum accounts, enabling users to control their digital identities through Ethereum accounts and ENS configuration files without relying on traditional middlemen. It is currently used in Web3 with the aim of standardizing on best practices and making Web2 services easier to adopt.)
secondary title
Amendment and revocation of certification
Alice completes her degree at a college and gets a digital degree record, signed with the college's key. Later, Alice's degree was revoked due to plagiarism in her thesis. But Alice continues to use her old electronic degree records to claim that she has a degree. This authentication might carry privileges, such as the right to log into an online forum at the academy, which Alice might have improperly accessed. How can we prevent this?
The "blockchain maximization" approach is to make the degree an on-chain NFT, so that the academy can issue an on-chain transaction to revoke the NFT. But it may be difficult to avoid expensive fees. Issues are common, revocations are rare, and we don't want to require the academy to issue transactions and pay for every issue unnecessarily. Therefore, we can adopt a hybrid solution: set the initial degree to sign the message off-chain, and do the revocation on-chain. This is the digital certificate method used by the Singapore government-level project OpenCerts.I would suggest that it is best to keep the system decentralized and only use the blockchain, especially now that rollups, forks and other technologies are finally starting to come online and the cost of the blockchain is getting lower and lower.
negative reputation
secondary title
negative reputation
Another key point that off-chain signatures are difficult to meet is negative reputation (the person or organization you are authenticating may not want you to see their authentication). "Negative reputation" is used here as a technical term: the most obvious incentive use case is to prove someone bad, such as a malicious comment or a report of someone's abusive behavior in certain circumstances, but there are also "negative" proofs that don't mean bad Behavioral use cases. For example, applying for a loan and want to demonstrate that you haven't applied for too many other loans at the same time.
Authentication on-chain does solve the problem. To protect privacy, we can add encryption and zero-knowledge proofs: an authentication can be just an on-chain record, the data is encrypted to the receiver's public key, and the user can prove that there are no negative reputation. The evidence is on-chain, and the verification process is blockchain-aware, so the evidence can be easily verified and no records are skipped. To be computationally feasible, users can use incrementally verifiable computations (such as Halo) to maintain and prove their encrypted records, and then reveal parts of the records when needed.
Negative reputation and revoked accreditation are in a sense equivalent problems: you can revoke a certification by adding another negative reputation accreditation and say "the other accreditation doesn't count anymore". You can undo negative reputation by attaching positive reputation.
secondary title
Is a negative reputation a good idea?
Is displaying a negative reputation a dystopia? Shouldn't we be doing our best to do something that has a positive reputation?
While I support avoiding 100% of negative reputations, I disagree with the idea of avoiding negative reputations entirely. Negative reputation is important for many use cases. Unsecured loans are extremely valuable for improving capital efficiency on and off the blockchain. Unirep Social, where I spoke at the Ethereum Shanghai Summit, demonstrated a proof-of-concept social media platform that combines high levels of anonymity with a privacy-preserving negative reputation system with the goal of limiting abuse.
Imagine an anonymous reputation system for sex worker clients, protecting privacy requires a system. If a client abuses a sex worker, they are blacklisted to remind other sex workers to be careful. In this way, a negative reputation that cannot be hidden can actually empower the vulnerable and keep them safe. The point here is not to maintain some particular negative reputation. Rather, it is meant to demonstrate the real value of a negative reputation, and a successful system needs to support it in some way.
A negative reputation doesn't have to be a 100% negative reputation. I think it is possible to create a new profile at some cost (possibly sacrificing much or all of the existing positive reputation). There is a balance between too little accountability and too much accountability. But first, having the technology to bring negative reputation scoring metrics to the blockchain is a prerequisite to unlocking the field.
secondary title
scarcity of promises
Another example of blockchain's value is the issuance of a limited number of proofs. If I want to endorse someone (eg a company or a government visa program is looking at such endorsements), a third party looking at the endorsement will want to know if I'm being cautious about the endorsement.
A more efficient use case is to publish multiple times at once. If an artist wants to release N copies of a "limited edition" NFT, a hash containing the Merkle root of the NFT being released can be published on-chain. A single issue prevents them from issuing more after the fact, and you can publish a number (eg 100) to denote the quantity limit and a 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 certifications. In this example, there are only 5 potentially valid Merkle branches that satisfy the proof check. Readers may notice its conceptual similarity to the off-chain scaling solution Plasma chain.
secondary title
Common Knowledge
Common sense (or disclosure) is important for coordination. For example, a group of people may want to have an opinion on an issue, but they will only feel comfortable in the safety of their numbers if enough people do so at the same time. Say, one starts a "commitment pool" around a particular statement and invites others to post hashes (private at first) that represent their agreement. Only after enough people have participated for a period of time will all participants be asked to publish their next on-chain message to make their position known.
Such a design can be accomplished through the combination of zero-knowledge proof and blockchain. It could be done without a blockchain, but that would either require witness encryption (not available yet), or trusted hardware, which has serious problems with security assumptions. There is a large design space around these kinds of ideas, which is currently underexploited, but will accelerate growth once the ecosystem around blockchain and cryptographic tools develops further.
secondary titleInteroperability with other blockchain applications
Proof of humanity is an on-chain NFT that makes it easier for projects to automatically airdrop or give account governance rights to someone with a proof of humanity profile. The oracle data chain makes DeFi projects easier to read. In these cases, the blockchain does not eliminate the need for trust, although it can accommodate structures such as DAOs that manage trust. But the main value provided on the chain is just being in the same place with the things you interact with, which requires the participation of the blockchain.
Of course, you could run an oracle off-chain and only ask to import data when it needs to be read, which in many cases is actually more expensive and introduces unnecessary complexity and cost to developers.
secondary title
open source metrics
Another measure and score value is the reputation system. This exists in the form of a centralized rating, but it can be achieved in a more decentralized manner, with transparent algorithms while retaining more user privacy. Beyond tightly coupled use cases like this, there are broader use cases that help the community understand itself. Instead of trying to abolish quantitative metrics, we should try to develop better metrics.
Kate Sills is skeptical about the goal of calculating reputation:"Assessing a process is very subjective and contextual. People will naturally disagree on the trustworthiness of others, and trust depends on circumstances... We should be extreme about any proposal to 'calculate' claims to obtain objective results skeptical."
In this case, I agree that subjectivity and context matter, but I disagree that avoiding calculations around reputation altogether is the right thing to do.
All complex societies attempting to support large-scale cooperation must rely to some extent on aggregation and simplification.
I think an open and participatory authentication ecosystem (as opposed to the centralized ones we have today) can bring the best of both worlds by making room for better metrics. Here are some principles that such designs can follow:
Inter-subjectivity: reputation should not be a single overall score; instead, it should be a more subjective calculation that includes the person or entity being assessed, and the viewer checking the score;
Credible neutrality: the way to achieve this is maximum transparency and infrequent algorithm changes;
If we fail to create good large-scale aggregation of social data, then we risk ceding market share to opaque and centralized social credit scores.
Not all data should be on-chain, but exposing some data in the form of public content can help improve the legibility of the community itself without creating discrepancies in data access that can be abused and centrally controlled.
secondary title
as data storage
This is a really controversial use case. There is a common view in the blockchain field - blockchain should only be used when it is really necessary and unavoidable, and elsewhere we should use other tools.
This makes sense in a world where transaction fees are very expensive and blockchains are terribly inefficient. But in a world where blockchains rollup and fork, transaction fees drop to pennies, and the slight difference between blockchain and non-blockchain decentralized storage can be as little as 100x, it doesn't mean much.
It also doesn't make sense to store all data on-chain. But why do small text records make sense? Because the blockchain is a very convenient place to store things. I keep a copy of this article on IPFS. But uploading to IPFS usually takes an hour, it requires a centralized gateway, and occasionally files are lost. On the other hand, dumping the entire article on-chain can completely solve this problem. Of course, the article is too large to be dumped on-chain even after the fork. But the same principle applies to records with small content.
Examples of the right decision to put data on-chain just for storage include:
Enhanced password sharing: Split your password into N parts, where M=NR parts can recover the password, but you can choose the content of all N parts. For example, these fragments could all be password hashes, passwords generated by other tools, or answers to security questions. This is achieved by publishing an additional R pieces on-chain (seemingly at random), and sharing the password N/N (N+R) times across 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 get the full data from IPFS. But this would add significant complexity and add another software dependency. Therefore, even if the data is longer than 32 bytes, ENS will keep it on-chain.
Social metadata: data connected to your account (eg for sign-in-with-Ethereum), you want to expose data, and very short in length. This is usually not the case for large data like avatars (it would work if the image happened to be a small SVG file), but it really isn't for the case of text records.Authentication and access rights: If the data being stored is less than a few hundred bytes in length, it may be more convenient to store the data on-chain than to put the hash on-chain and the data off-chain.
Sometimes the data is particularly sensitive, which is another argument against putting it on-chain and storing it locally as a second layer of defense. In these cases, the need for privacy is an argument not just against blockchains, but against all decentralized storage.
Summarize
secondary titleSummarize
Of the above application scenarios, the two areas where I am personally most confident are interoperability with other blockchain applications and account management.
The first is already on-chain, the second is relatively cheap (requiring the blockchain to be used once per user, not once per operation), and we can see that there really isn't a good non-blockchain solution.
Negative reputation and revocation are also important, although still relatively early use cases. By relying solely on positive reputation off-chain, there is a lot of room for the reputation system to grow, but the application of revocation and negative reputation will become clearer as it evolves. Expect someone to try to do this with centralized servers, but over time it will be understood that blockchain is the only way to avoid the difficult choice between inconvenience and centralization.
