There has been an increase in interest in blockchains being used for more than just financial applications. For many reasons, this is a trend I strongly support. Collaboration to create a paper that outlines a deeper vision of what can be achieved with a richer ecosystem, soul-bound tokens that make claims about different types of relationships. There has been some discussion about whether it makes sense to use blockchains in a decentralized identity system.
- Kate Sills supports off-chain signed claims
- Puja Ohlhaver replies to Kate Sills
- Evin McMullen, myself, and a podcast discussing off-chain vs on-chain attestations
- Kevin Yu provides a technical overview that addresses the question of on-chain versus offline chain
- Molly White makes a pessimistic argument against self-sovereignty
- Shrey Jain creates a meta-thread that includes the above and many other Twitter conversations
It is worth looking out and asking a larger question: Where does it make sense to use a Blockchain in non-financial apps? Do we want to see chat apps that work in a decentralized manner, with every message being an encrypted message and each financial transaction on-chain? Alternately, blockchains are only useful for finance (e.g., network effects mean that money has a unique need for a global view), with all other applications being better done using centralized systems or more local ones.
My view tends towards being, as with blockchain voting: far from the "blockchain everywhere” viewpoint but also far away from a "blockchain minimalist". Blockchain networks are valuable in many circumstances. Sometimes they can be used to achieve important goals such as trust and resistance to censorship, but other times they can simply be useful for convenience.
This article will discuss some situations in which blockchains can be used, particularly in the context of identity verification. This is not an exhaustive list, and it intentionally leaves out many items. The purpose of this post is to clarify some common categories.
Recovery and key changes to user account keys
The issue of key changes is one of the most difficult aspects of a cryptographic account system. In some cases, this can occur:
- You are concerned that your current key could be lost or stolen and want to change to a new key.
- You wish to change to another cryptographic algorithm (e.g. Because you are worried about quantum computers coming soon and want to upgrade to postquantum.
- You lost your key and want to gain access to your account again
- You lost your key and want to get access to your account again.
Both [1] and[2] can be done in a completely self-sovereign manner. You control key X and want to switch to key Y. So you publish a message signed by X that says "Authenticate me with Y now". Everyone accepts it.
You should also be aware that you cannot only use cryptography for these simple key change scenarios. Take a look at the following sequence of events.
- So you are concerned that key A could be stolen, so you send A a message saying "I use A now"
- One year later, the hacker has managed to steal key A. They sign a message with A that says "I use C now", which is their key.
These messages are seen from the perspective of someone who comes in later and just receives these two messages. They see that A is no more used but don't know if "replace B with B" or "replace C with A" has a higher priority.
This is similar to the double-spend problem when designing decentralized currencies. However, instead of the goal of stopping a previous owner from sending it again, the goal here is to stop the previous key controlling accounts from being in a position to change the key. A blockchain is required to manage accounts in a decentralized manner, just like the creation of a decentralized currency. Blockchains can timestamp key messages and provide common knowledge about whether A or C was first.
The harder ones are 3 and 4. My preferred solution is multisig wallets and social recovery wallets. This allows friends, family, and other contacts to transfer control of your account to another key if it is lost or stolen. Critical operations, such as. Participation in this group is also possible for critical operations (e.g., transferring large amounts of money or signing an important agreement).
This also requires a private blockchain. Although social recovery via secret sharing is possible in theory, it is much more difficult in practice. If you don't trust your contacts or they wish to change their keys, there is no way to revoke access to your key without changing your own. We are back to the requirement of an on-chain record.
The doc paper contains a subtle, but crucial idea. To preserve non-transferability social recovery (or "community recuperation") of profiles might need to be mandatory. This means that even if your account is sold, you can still use community recovery to get it back.
This would solve problems like not-actually-reputable drivers buying verified accounts on ride-sharing platforms. This is just speculation and should not be implemented in full to reap the benefits of blockchain-based reputation and identity solution systems.
This is only a small use case for public blockchains. It's perfectly acceptable to have accounts on-chain and do everything else off-chain. These hybrid visions are possible. Sign-in with Ethereum is a good example.
Modifying and revoking attestations
Alice attends Example College to get a degree in example studies. Alice receives a digital crypto asset record that certifies this, signed by Example College's keys. Six months later, Example College learns that Alice has committed large amounts of plagiarism and she is denied her degree.
Alice still uses her old digital currency record to claim to different institutions and people that she has a degree. The attestation might even contain permissions, such as the right to log into the college's online forum. Alice could also try to misuse that privilege. How can we stop this?
Blockchain maximalists would make the degree an NFT on-chain, so Example College could issue an on-chain transaction to revoke that NFT. This approach is expensive because issuance is common and revocation is uncommon. We don't want Example College to pay fees for each transaction if they don’t need to. Instead, we could use a hybrid approach: Make the initial degree an off-chain signed message and do revocations only on-chain. This is what OpenCerts uses.
The only off-chain solution and one that many proponents of off-chain verifiable credentials advocate is that Example College maintains a server on which they publish a complete list of all their revocations. To improve careers privacy terms, each attestation may come with an attached nonce, or the revocation list could be just a list.
Running a server for a college isn't a major burden. IT professionals can find it difficult to manage "yet another server script" and ensure that it is online for smaller organizations or individuals. We can tell people to just use a server out of blockchain phobia. The likely outcome is that everyone will outsource the task to a central provider.
It is better to keep the system centralized and use a single blockchain, especially since rollups and sharding are becoming more affordable.
Negative reputation
Negative reputation is another area where off-chain signatures are not sufficient. This is an attestation that the person or organization you are attesting about may not wish you to see them. As a technical term, I am using "negative reputation" as the following: Attestations that say bad things about someone are the most obvious. However, there are other use cases in which "negative" attestations do not imply bad behavior. For example, if you take out a loan but want to prove that your credit history does not include multiple loans.
Off-chain claims can have a positive reputation. This is because it's in someone's best interest to make the claim look more credible (or to make ZK-proof of it). A negative reputation can't be done because you can always choose to show only the claims that make you look good.
Making attestations on-chain is a good way to fix things. We can use encryption and zero-knowledge verifications to protect privacy: An attestation can be an on-chain record with data that is encrypted to the recipient's key. Users could also run a zero knowledge test that walks through the chain's entire history.
Because the proofs are on-chain, and the verification process is blockchain-aware, it's easy to verify that the proof did indeed walk over the entire history without missing any records. This could be made computationally possible by using incrementally verifiable computations (e.g. To maintain and prove a tree that was encrypted to them, Halo can then reveal portions of the tree as needed.
Negative reputation and revoking attestations are in some ways equivalent problems. You can revoke an attestation by adding another negative-reputation attestation saying "this other attestation doesn’t count anymore" and you can also implement a negative reputation with the revocation of a positive reputation by piggybacking off a positive reputation. Alice's example college degree could be revoked to replace it with one saying "Alice obtained a degree in example study, but she borrowed money".
Is it a good idea to have a bad reputation?
We hear a lot of criticisms of negative reputation. But isn't it a dystopian scheme with "scarlet letters"? Shouldn't we do our best to build a positive reputation?
While I agree to intend to avoid unlimited negative perceptions, I don't think it is possible to completely avoid them. For many uses, a negative reputation is essential. It is a great way to improve capital efficiency in the blockchain space as well as outside. United Social presents a proof of concept social media platform, Unirep Social. It combines anonymity with privacy-preserving negative reputation systems to limit abuse.
A negative reputation can sometimes be positive and a negative reputation can sometimes be debilitating. A forum where everyone can post, regardless of their misbehavior, is more egalitarian than one that requires proof of good character to be allowed to talk. People who are marginalized and live mostly "outside" the system, even if they are actually of good character, might have trouble getting such proof.
Readers who are of strong civil-libertarian convictions may want to think about the case for an anonymous reputation system for clients of sex workers. You want privacy but also want to encourage other workers to be more cautious or to stay away from clients who mistreat sex workers.
This is how a hard-to-hide negative reputation can empower vulnerable people and provide safety. This is not a defense of a particular scheme to create a negative reputation. It's to demonstrate that there's real value in a negative reputation and that if viewed correctly, thereby empowering the vulnerable and protecting their safety.
A negative reputation doesn't have to be an unresolved reputation. I believe it is possible to build a new profile at some price (perhaps even sacrificing some of your positive reputations). There is a fine line between too little and too much accountability. However, any blockchain technology that creates a negative reputation is necessary to unlock this design space.
Simplifying the process of reducing scarcity
Blockchain technology can also be used to issue attestations with a limited number of signatures. I can endorse someone, such as. One might think of a company looking to hire or sponsor a visa program. The third-party reviewing the endorsement would want information about my ethics and whether or not I trust people enough to give them endorsements.
This problem could be solved by making endorsements public so that they become incentive-aligned. If I endorse someone who does something wrong, then everyone can disregard my endorsements in the future. We often want privacy. Instead, I could publish the hashes of each endorsement on a chain so anyone can see how many I have given.
A more efficient use case is multiple-at-a-time issuance. If an artist wants to issue N copies of a "limited edition" NFT, they can publish on-chain a single hash that contains the Merkle root for the NFTs they are issuing. You can publish the number (e.g. 100 is the Merkle root and the quantity limit. This means that only the 100 Merkle branches left are valid.
You can only publish a single Merkle root, max count, and commit to issuing a small number of attestations. This example shows that there are only five valid Merkle branches that can satisfy the proof-check. For those who are more observant, there may be a conceptual similarity with Plasma chains.
Common knowledge
Blockchains have the unique property of creating common knowledge. If I publish something, Alice can view it. Alice can also see Bob can, Charlie can see Alice can, and so forth.
It is important to have common knowledge for coordination. A group of people may want to discuss a topic, but they will only feel safe if there are enough of them.
One way to achieve this is to have one person create a "commitment pool", and invite others to post initially private hashes, denoting their agreement. Participants would need to make their next on-chain message public if they have enough participants within a certain time.
This design could be achieved with a combination of zero-knowledge proofs as well as blockchains. However, it would require witness encryption which is not yet possible, or trusted hardware which has very problematic security assumptions.
These kinds of ideas offer a lot of design potential that is not being explored today. However, it could quickly grow as the cryptographic tools and blockchain ecosystem grows.
Interoperability of other blockchain applications
This is a simple one: certain things should be on the chain to make it easier for other applications to interoperate. On-chain NFT Proof of Humanity allows projects to airdrop accounts with proof of humanity profiles and give governance rights. Definitive projects can read Oracle data because it is on-chain.
The blockchain is not able to remove trust in any of these situations, but it can contain structures such as DAOs that manage the trust. The main benefit of being on-chain is being in the same spot as the stuff you interact with. This requires a blockchain for other reasons.
You could certainly run an oracle on-chain and only require that the data be imported when it is needed to read, but this would be a costly and unnecessary burden on developers.
Open-source metrics
The Decentralized Society paper has as its main goal the ability to calculate over the graph of attestations. One of the most important is measuring diversity and decentralization. Many people agree that the ideal voting system would consider diversity and give more weight to projects supported by coins, humans, or truly unique perspectives.
Quadratic funding, as it is implemented in Gitcoin Grants, also includes explicit diversity-favoring logic to mitigate attacks.
Reputation systems are another place where scores and measurements can be of value. It is already possible to do this in a centralized form with ratings. However, it is possible to do it in a more decentralized manner where the algorithm can be transparent and users are protected more.
Apart from closely-coupled cases such as this, which attempt to determine how many people are connected and feed it into a mechanism directly, there is also the wider use case of helping a group understand itself. This could be used to identify areas of high concentration, which may require a response. All of these cases will require the use of blockchain computerized algorithms to analyze large amounts of commitments and attestations and then do important things with the outputs.
Quantified metrics should not be abolished. We should instead try to create better ones
Kate Sills expressed doubt about the goal to make calculations over reputation. This argument applies both to public analytics as well as for individuals ZK-proving their reputation (as in Unirep Social).
In this instance, while I recognize the importance of context and subjectivity, I disagree with the assertion that it is best to avoid reputation calculations altogether. A pure individual analysis is not sufficient to scale beyond Dunbar's numbers. Any complex society that wants to support large-scale cooperation must rely on simplifications and aggregations to some degree.
However, I believe that an open-participation system of attestations can offer the best of both worlds. It opens up the possibility of better metrics. These are some principles to consider when designing such systems:
- Inter-subjectivity: eg. A reputation is not a single score. It should be subjective and involve the person or entity being evaluated, as well as the viewer who may be checking the score and possibly other aspects of the local context.
- Credible neutrality The scheme should not allow powerful elites to manipulate it in their favor. This can be achieved by ensuring maximum transparency and not changing the algorithm often.
- Openness - Anyone should have the ability to input meaningful information and audit the outputs of others by running the check themselves. This is not a privilege that should be restricted to powerful individuals.
We risk losing market share to opaque, centralized social credit scores if we fail to create large-scale aggregates that are reliable and accurate.
While not all data should be available on-chain, making some information public in a common-knowledge manner can increase a community’s legibility without creating data-access gaps that could be used to centralize control.
Datastore
Even among most people who accept other digital assets, this is the controversial one. The consensus in the blockchain space is that blockchains should be used only in necessary cases, and other tools should be used wherever else.
In a world with high transaction fees and extremely inefficient blockchains, this attitude is understandable. It makes little sense in a world with rollups and transaction fees that are only a few cents. The difference in redundancy between non-blockchain storage and blockchain may be as low as 100x.
It would be absurd to store all information on-chain even in such a world. But what about small text records? Absolutely. Why? Because blockchains can be used to store things in a very convenient way. This blog is also available on IPFS. Uploading to IPFS can take up to an hour. It requires blockchain centralized gateways to allow the user experience to access it with any level of latency. Files sometimes drop off and are not visible anymore.
The solution to this problem is to dump the entire blog onto the chain. Although the blog is too large to be thrown on the chain, even after sharding, the same principle applies to smaller records.
Here are some examples of small cases in which storing data on-chain to store it might be the right choice:
- Augmented secret sharing is a method of splitting your password into n pieces. Any M=R can retrieve the password. However, you can choose the content of all n pieces. The pieces could be password hashes, secrets generated by another tool, or answers to security questions. This is done by publishing additional R pieces on-chain (which are random-looking), and doing N - of (N+R) secret sharing on the entire set.
- ENS optimization - could be more efficient by combining all records in a single hash and publishing it on-chain. Industry leaders accessing the data will need to use IPFS to obtain the complete data. This would increase complexity and add another software dependency. ENS, therefore, keeps data on-chain, even if it's longer than 32 bytes.
- Social metadata is data that is connected to your account (e.g. for sign-in-with-Ethereum purposes) that you want to be public and that is very short in length. For larger data, such as profile pictures, this is not usually true. However, it may be true if the image happens to be in a small SVG format. However, it is true for text records.
- Access permissions and attestations - If the data to be stored is smaller than a few hundred bytes, it may be easier to store it on-chain rather than the hash on the chain and the data off the chain.
These cases are not only about cost but privacy in the case of cryptography or keys being lost. Privacy is not always essential. The occasional loss of privacy due to leaked keys, or the distant specter that quantum computing will reveal everything in 30 years, is more important than the ability to have a high degree of confidence that the data will be accessible. Off-chain data in your "data wallet", can also be hacked.
Sometimes data can be extremely sensitive and this could be an argument against having it on-chain and keeping it locally as a second layer. However, in these cases, terms privacy needs are not an argument against blockchains but also all distributed storage.
Conclusions
Interoperability and account management are the two things I feel most confident about from the above list. Both the first and second are already on-chain. The case for the latter is strong, as there is no good alternative to blockchain-based solutions.
Revocations and negative reputations are important as well, even though they are still in their early stages. Although many things can be done to improve reputation, I believe the case for revocation or a negative reputation will grow over time. While I anticipate there will be efforts to do secure customer experience so with centralized servers in the future, it should become evident that the applications of blockchain are the best way to avoid inconvenience or centralization.
Although blockchains may not be used as data storage for short text records, I expect some users to continue secure experiences. Blockchain solutions are incredibly convenient for reliable and cheap data retrieval. Data can be retrieved regardless of how many users an application has.
Open-source metrics remain a concept in their early stages. It is still unclear how much more can be done, made open and not exploitable. Online reviews, social media karma, and other such things are all being exploited constantly. Common knowledge games involve convincing people to accept new workflows for socially-important things. This is also an early-stage idea.
Although I am unsure as to the exact level of non-financial use of blockchains in each of these categories, it seems obvious that they are an enabling tool.
