Identity and Reputation in a Web 3.0 World
Editor's Note: This article comes fromCarbon chain valueCarbon chain value
, Author: Sina Habibian, translation & proofreading: IAN LIU & Elisa, published with permission.
secondary title
Why Identity & Reputation Matters
Let's start by understanding how identity and reputation can unlock value at the protocol level.
Turning a one-shot game into a repeated game"work token"Blockchain users are anonymous, and the cost of replacing a new address is negligible, so it is difficult for consensus protocols to require users to perform legitimate actions. Today, we are used to constraining with the concept of pledge or "punishment condition", which essentially punishes evil behavior by confiscating some of the participants' funds (usually ETH or ERC20 tokens).
Assuming that we have a way to digitally reflect the scarcity of identity and reputation, we can modify the existing equity mechanism and use the same method as confiscating funds to cause the reputation of the perpetrator to suffer. Conversely, the consensus protocol can also reward participants with high reputation; such as giving them more benefits in the network (can be compared with the work tokens mentioned in the Cosmos and Keep projects
analogy). Participants have an incentive to optimize their reputations, not just for short-term gain; thus turning a one-time game into a repeated game.
sampling
Regarding sampling, the most important application is the consensus mechanism itself (like Proof-of-Work and Proof-of-Stake undertake anti-Sybil authentication). This can be extended to other use cases, such as choosing who stores files, or who performs computational work in a resource marketplace.
Network services meet the needs of different levels of customer groups through many current limiting and pricing strategies. Take Dropbox, for example, which uses a freemium model (anyone can use the service for free, but the free service is limited). Through the identity system, decentralized protocols can also achieve similar functions. Like Filecoin, it can use the freemium model to provide lower prices to users with large needs.
governance
In addition to the protocol layer, we also see that many applications require identity.
governance
The existing blockchain voting system is based on the token voting model. Tokens are scarce resources and provide an anti-sybil attack mechanism, but this also leads to the dictatorship of the plutocrats, and the rich have a greater right to speak. Mechanisms such as Quartic Voting, although able to reduce the impact of wealth, can still exploit loopholes; for example, one party spreads money to multiple account addresses.
Reputation comes from the user's previous behavior in the protocol, or from the community's trust in the user; it can be used as the basis for determining the voting weight of a certain node.
borrow money
Needless to say, the requirements for secure on-chain voting are more stringent than the above. For example, to avoid vote-buying, participants should not be able to disclose how they voted.
borrow money
The on-chain lending protocol cannot trust participants, so it requires full collateral to borrow. This high borrowing cost curbs the development of applications.
Identity systems turn this around by verifying some real-world characteristics of the borrower (credit history, proof of title, income, etc.). Reputation, secured by previous lending experience or other people, can be considered collateral.
Security Tokens
Tokenization of real-world collateral, such as real estate, equity, and artwork, can amplify their value: the value-added point is that tokens can reflect partial ownership, have the advantages of timely clearing and settlement, and participate in the 7*24 global market. The issuance and trading of such tokens must comply with securities laws (KYC, AML, qualification verification, and other inspections for transaction participants), and these conditions and restrictions can be internalized into the token itself (such as R-Token using the Harbor method) Or enforced at the time of exchange delivery (such as implementing such restrictions before calling the ERC20 transfer function on a decentralized exchange).
Token airdrops incentivize participants in the network. Some recent examples of airdrops, such as Livepeer's Merkle Mine and Handshake's airdrop, are open source airdrop mechanisms. With the identity and reputation system in place, we are able to design more granular airdrop distribution mechanisms. The application of identity and reputation here includes: building social attributes of games on the chain (for example, the popularity of in-game items will affect their prices), login and authority control, DPoS, universal minimum income, and aggregate decentralization input to the oracle.
Next, let's take a look at what identity and reputation really mean.
secondary title
What do we mean by identity and reputation?
Identity is the most fundamental role in the system. In Ethereum, it can be said that the Ethereum account address is the identity.
Identity can be used to prove that something happened between yourself and others, we call these things claims. Over time, reputations are built along with identity systems.
Protocols for identity, claims, and reputation should interact with each other through appropriate interfaces. The system must be modular and scalable, with the following properties:
Decentralization: Protocol rules should be formulated and followed by network participants, rather than enforced by a centralized authority.
Self-sovereignty: Users are in control of their own identities, claims, and reputations. This is in stark contrast to Web 2 networks; in Web 2 networks, such as Amazon; a merchant's product's accumulated reputation can be removed due to Amazon's bankruptcy or unilateral decision.
Portability & interoperability: The system should not detain users, but should allow users to migrate their own data to other systems.
Privacy: Participants should be able to selectively share data with others. In addition, the identity of participants can be verified by private identities by default.
identity
Next, let's dive into the three components of this system: Identity, Claims, and Reputation.
identity
An identity can refer to an externally held account (controlled by a private key), or a smart contract (multi-signature, DAO, etc.). Identities can be used to sign messages, encrypt data, or make statements about oneself or others.
In identity management, key management is the most important part. The biggest difference from private keys is that using smart contracts to manage identities allows us to expand some functions, such as key retrieval, permission control, dynamic spending limits, and more.
Identity management contracts should include key recovery mechanisms in the face of:
Key missing (lost user rights)
Stolen keys (user has permissions, thief has permissions)
The key is stolen and lost (the user's rights are lost, the thief has them)
There are a number of mechanisms that can come in handy here: community recall, suspension of attestation services, or via Shamir key sharing and Schnorr signature methods.
Finally, the identity method must have good interoperability with other systems and be compatible with the W3C DID (Decentralized Identifier) standard.
statement
secondary title
statement
A claim refers to a fact that is made by one identity to another.
The semantics of a "claim" follows "an entity makes a claim about some subject", and can express many things:
"A declares that B has passed KYC." - for anti-Sybil attacks
"A declares that B is a qualified investor." - for regulatory compliance (such as token sales, and mortgage token transactions, etc.)
"A declares that B is over the age of 21." - for age-restricted products
"A declares that B is a Chinese citizen." - for compliance review
"A declares that B has x revenue." - for credit risk guarantees
These statements are signed by the declarant so their authenticity and integrity can be cryptographically verified.
Either party can also make statements about itself (eg name, nationality, birthday).
There are some design guidelines to keep in mind:
Claims should be encrypted: Claims may contain sensitive information and should therefore always be stored in encrypted form. Data owners can share data with specific identity objects in an optional information disclosure process (for example, exchange keys through Diffie-Hellman method).
Store as little data as possible onchain: unless onchain review is required (for example, an ERC20 transaction that requires permission), declare that data should be stored off-chain and only on-chain Store its encrypted form (eg, the root value of a Merkle tree). In addition, considering the popularity of quantum computing in the future and the vulnerability of the current encryption system, even if the data has been encrypted, it should not be stored on the blockchain.
Now, let's look at some design scenarios.
accomplish
ERC 725/735
secondary title
accomplish
ERC 725 is a proposal on smart contract identity, which implements a standardized interface for managing identity claims, and the deployment number is ERC 735. Users are required to approve all claims related to them and can delete them at any time. Because this system does not require multi-party coordination, it can be upgraded.
ERC 780
This proposal also has some problems. Because each identity has to deploy its own claims contract, there is no guarantee that all will comply with the specifications in ERC 735. So when validators work with these identities, they first have to check their source code; this is very inconvenient. Worse, allowing users to directly delete claims about them prevents the entire system from posting negative claims.
Finally, when it comes to privacy protection, ERC 725 needs to be paired with an off-chain system because it stores all claims on-chain.
Zeppelin TPL
ERC 780 proposes to establish a global registry on Ethereum to store all claims on Ethereum. uPort uses the registry as the basis for building a decentralized PKI system, with the goal of moving most claims off-chain. The registry does not distinguish whether the declarer is an account or a contract; and because there is only one contract, all verifiers can trust its logic.
The problem with this proposal is that the statement is limited in its expressiveness. This directly leads to limitations in usage because all declarations are required to conform to the same data structure. It can also be troublesome when doing an upgrade because it requires support from a wide range of stakeholders.
Zeppelin TPL (Transaction Processing Layer, Transaction Processing Layer) is designed for permissioned transactions of ERC20 tokens. In this scheme different contracts are deployed for each "jurisdiction". The management clusters of a "jurisdiction" elect certificate issuers who have the authority to write claims into the claims registry for that jurisdiction.
This is a more practical design. Verifiers place more trust in jurisdictional claims because they know those claimers are certified. But on the other hand, only some users are allowed to issue statements, which will inevitably lead to reduced system flexibility.
NFT-based identity
Solution
We can encode the license in the form of NFT (Non-Fungible Token, non-substitutable token), and a group of authoritative nodes can produce NFT for users, which can be used by users after verification. The problem here is that users are able to trade their NFTs, and the design doesn't mention the advantages of using NFTs over claims.
Solution
There is a possible system that combines the advantages of the above approaches: it's called the Joint Claims Registry.
Next, we get to the reputation section.
reputation
secondary title
reputation
Reputation Based on Trust Graph
thought experiment
This method is derived from the social network algorithm, PageRank, and has many similarities with delegated democracy.
thought experiment
Imagine airdropping 100 trust tokens to each Ethereum account prior to a large vote, and giving them the freedom to delegate trust tokens to someone who can represent their vote.
After the election of appointed nodes, each appointed node starts to vote. Voting weights are based on the number of trust tokens they have received, either directly using the total number of tokens obtained, or using a metric coefficient like PageRank.
In our case, each line in the graph can be regarded as a distribution of trust tokens. The PageRank method recursively gathers the wisdom of the crowd. If many people assign trust tokens to A, then the tokens assigned by A to other people will have higher weights; The weight will be higher again. Iterating in this way, reputations get as close as possible to their true weights.
image description
Source: https://en.wikipedia.org/wiki/PageRank
Note that this approach can also be implemented in declarative protocols. Trust tokens aside, users can also express the lines in the graph above with statements to other people. However, we can also see that there are some problems in the method based on the trust map.
Anti-Sybil attack
An attacker can sign multiple identities and make them trust each other, artificially boosting the reputation of these nodes. There are several workarounds:
(1) Trustworthy identity
There is a parameter E(u) in the basic PageRank algorithm, which allows people who crawl web pages to jump to a preset web page with a certain probability. Doing this prevents crawlers from getting stuck in a sybil subnet.
Similarly, in our use case, trusted identities can be set in advance; they can also be selected from a set of identities that have been verified in the real world.
(2) Local reputation
Everyone can calculate reputation locally. For example, in lending scenarios, the guarantor can only assess the risk of the borrower from the interaction of each user with himself and other trusted identities.
Interestingly, if a user is trusted by most nodes on the Internet, the trust from the global perspective will also be close to the local perspective. This is similar to how, in lending theory, an IOU from a creditworthy party can also represent money.
(3) Trust circulation channels created by scarce resources
We can also manually analyze the trust graph and filter out some results after analysis. For example, a group of nodes that trust each other, but are not trusted by those outside the group, is likely to be considered problematic and removed.
Incentives
secondary title
Incentives
In the trust graph, what motivation do users have to create the correct trust circulation channel?
The operation of P2P lending and insurance (eg, TrustDavis) may bring us a potential answer, which is that nodes provide collateral in order to obtain channels. If the collateral they provide is in circulation, they can get benefits; otherwise, if they do evil, they will lose the collateral.
Another possible answer is to create additional spin-offs as channels of trust based on existing behavior. For example, publishers add high-quality links to their websites to attract users, so publishers provide the required data for PageRank. Similarly, for a developer to create a good code base and attract more contributors, it must maintain a friendly development environment; in this way, they create the circulation channel that Sourcecred needs (recommend you to take a look at Dandelion ).
Another kind of reputation is based on behavioral evaluation.
Behavior-Based Reputation
In this method, we do not rely on the map to determine the reputation, but each person evaluates the other party's historical behavior. For example, in the Dharma lending agreement, the reputation of borrowers can be calculated based on their payment history and timeline; in Truebit, the reputation calculation is based on tasks successfully solved in the past.
We're also able to build this type of reputation into the protocol; as users improve their reputation, they can get bigger discounts on fees or higher income in the network.
The above method relies on a Sybil-resistant identity system to work. Because if there is no identity system, anyone can improve their reputation by fake workload.
Another annoying problem is that people can gradually build up their reputation and then end up with a scam. This has happened to exchanges and bitcoin lending platforms before, so this reputation program must be rigorously analyzed and take into account the economic cost of Byzantine behaviour.
Finally, we need to continue to explore the concept of "negative reputation". If an identity is likely to have a reputation rating below zero, they may be inclined to jettison their existing identity and rejoin with a new one.
in conclusion
in conclusion
thank you
Identity and reputation are important research topics. They can transform the protocol from a one-time game to a repeated game, and are an essential part of many blockchain applications, such as sampling, pricing strategies, governance, lending, collateral tokens and airdrops, etc.
