Alright friends, I asked and you delivered.
I will now do my best to return the favor - let’s dive into web3 identity.
I will define identity broadly as the set of traits or properties that uniquely define an autonomous agent. Our construction of our more granular definitions will build upon this, and the distinctions will depend heavily on what information we are looking to draw from the system.
Modern psychoanalytic theory delineates between contextual identities by their scope and behavioral qualities. These delineations typically include personal identity, social or relational identity, and community identity. Each type of identity exhibits distinct characteristics and behavioral patterns.
Identity affects how conscious agents view themselves, especially relative to the group. An individual’s view of themself within a community is affected by their perceived in-group/out-group position, and material symbols such as shared property can establish a clear separation line between members and outsiders, enhancing perceptions of group cohesion.
Acknowledging different levels of identity and the individual’s role in each will put the self-assembling behaviors of decentralized autonomous organizations and the action profiles of identity-bearing agents into better context.
Many of the active topics of conversation around identity in web3 are topics that were discussed in web2 and even web1. The key difference in web3 is a novel solution set centered around identity ownership and interoperability.
In web2, interoperability was primarily enabled through federated identity management, in which information stored across identity management systems could be linked, and single sign-on systems (SSO). The issue here is that identity data is owned and access controlled by organizations, corporations, and services rather than the individual to whom it belongs.
Web3 identity solutions center around user-centric ownership models. They also prioritize portability, with solutions promising a foundational identity layer that enables inherent information transferability, rather than retroactively fitted portability solutions as in web2.
With the introduction of multi-party and algorithmic identity-bearing agents, this concept of user-centric ownership has been further forced to expand under some models. As we explore different views of web3 identity, it will be important to keep this in mind.
When it comes to recognizing, classifying, and verifying identity on-chain, I see it being approached from two angles:
To make this distinction a bit more visceral, imagine for example that a credit-based lending protocol wants to analyze a user’s behavior prior to distributing a loan. The primary incentive on the protocol’s end is to prove something about the on-chain behavioral history of that agent, especially within the credit establisher’s own ecosystem. The protocol wants to protect its assets and know with some level of certainty that their funds will be returned, so the behavioral and transactional history of the agent may hold more weight than direct KYC.
In contrast, imagine that a protocol managing on-chain health records access receives a request for retrieval of a specific user’s data. In this case, the protocol designers are highly incentivized to establish a system that verifies the legal identity of the wallet owner and to be confident that the actor is who they say they are.
In these instances, we see the lending protocol approaching identity through the puppet view, weighing historical action patterns over explicit identity verification, and the medical records protocol approaching identity through the puppeteer view, weighing IRL identity verification over transactional history. Of course, each will do some due diligence in the other’s scope to protect against fraudulent outlier cases, and the two views are rarely mutually exclusive. Rather, each view is prioritized differently depending on the protocol’s primary perceived risk factors.
Now, when it comes to defining and verifying identity, a few distinct approaches pop up.
Elementary Unit: Wallet Address
Relational Pattern: Transaction History
Primary Incentive(s): Risk Mitigation, Network Benefits, Transaction History
Elementary Unit: Personhood
Relational Pattern: Biometric/Legal Verification
Primary Incentive(s): Sybil Resistance, Legal Compliance, Sensitive Data Exchange
Elementary Unit: Assets
Relational Pattern: Ownership
Primary Incentive(s): Skin-in-the-Game, Community Membership
Elementary Unit: Persona
Relational Pattern: Social Behaviors
Primary Incentive(s): Community Engagement, Vibe Curation
Elementary Unit: Reputation
Relational Pattern: Accomplishment Track Record
Primary Incentive(s): Contributor Quality, Experiential History Verification
Elementary Unit: Decentralized ID
Relational Pattern: On-chain Key to Off-Chain Storage Mapping
Primary Incentive(s): Data Ownership, Data Access Management
Along with defining identity, the web3 ecosystem is home to several services that build upon one or multiple of these identity definitions to facilitate access. The two service types i’d like to highlight under this umbrella are privacy and authentication services.
One component heavily integral to the conversation of identity preservation and identification is privacy. Enabling and facilitating user, data, and transactional privacy is critical for users to maintain ownership and control over their selected forms of representative identity. Thus, part of facilitating full identity ownership in a decentralized space is the enabling of anonymity, pseudo-anonymity, and selective access. These are concepts we’ve already seen play out in the data identity layers discussed earlier.
A cryptographic technique offering promise in the privacy space is Zero-Knowledge Proofs (ZKPs). ZKPs have an important place in scaling solutions and are more broadly being adopted as an infrastructural tool to preserve user privacy and enable services to operate without compromising sensitive information. A ZKP enables parties to prove a statement is true without disclosing any other data associated with it.
Several protocols, services, and currencies are developing privacy-first practices employing ZKPs and other tools that enable varied levels of transactional and personal anonymity. These include:
Another major service tied to identity is authentication. Depending on your selected definition of identity, a service provider’s methods of authentication may look different. Here are some examples of web3 authentication providers operating on a variety of identity standards:
I want to acknowledge the bias that westernized (particularly US-centric) technology can have, so I think it is important to include in my analysis some application spaces of identity tech that address basic human rights and needs. One of the most interesting lines of work recently brought to my attention is refugee identity management.
Some of us may have the privilege to never worry about having access to verifiable legal credentialing. However, standardized legal identification is not a universal practice, and it is also something that is frequently lost or never received by refugees. Being uprooted from your home country and transported into a new place with no verifiable reputational identity can make getting a job, finding housing, and functioning autonomously incredibly difficult. You may no longer have the ability to prove your degree status, your nationality, your birth date, etc.
Several blockchain-powered initiatives have begun popping up worldwide to support refugee resettlement by providing portable on-chain reputation systems and access to otherwise inaccessible financial services. Establishing provable identity metrics is a way to ensure global, uncompromised access to critical identity information. I have linked a few resources below for further reading.
A topic that often comes up in the discussion of identity in distributed systems is sybil-resistance. Put simply, a sybil attack is one in which a dishonest operator subverts a network’s reputation system by controlling several nodes under false identities. In vote or majority weighted systems, this can compromise the integrity of a vote and disrupt or falsify network consensus.
In the construction of a blockchain, establishing a consensus mechanism that defends against sybil attacks is critical. To accomplish this, networks rely on mechanisms of consensus that increase the friction to operating dishonest nodes and incentivize honest network participation. These consensus mechanisms tend to operate as “proof-of-X” systems, in which nodes need to prove something about themselves that, when proven, significantly decreases the likelihood of them being malicious. The most popular forms of consensus currently are proof-of-work and proof-of-stake. In proof-of-work, nodes are tasked with resource-intensive computational challenges. In proof-of-stake, nodes are required to maintain ownership of an asset in order to participate in the network. Other examples of blockchain consensus mechanisms include proof of history, proof-of-spacetime, and proof-of-activity.
Chain consensus is not the only place where sybil-resistance pops up in the decentralized ecosystem. As new and innovative identity layers emerge, it is becoming increasingly important to establish sybil-resistant practices which ensure that malicious actors do not take advantage of social networks or community governance systems. Worldcoin is a particularly interesting initiative operating in this space, aiming to develop a new, biometrically-linked proof-of-personhood primitive to power plug-and-play sybil-resistance at the application level.
For those of you unfamiliar with the data availability problem, it is the question of how “peers in a blockchain network [ensure] that all the data of a newly proposed block is actually available.” [The Data Availability Problem] While at first glance it may not seem like a problem of identity at all, the motivations behind it and the approaches to resolution reveal important questions around fraud prevention and trustworthy node identity. Critical to accurate network performance, as discussed above, is maintaining a majority of honestly acting nodes. Without full access to all block data, a block producer may be hiding malicious transaction data and/or compromising network security.
To ensure data availability, chains will construct artificial limits on block size to prevent resource-constraints that would price out many full node operators and thus risk network security and decentralization. These constraints, however, seriously hamper the ability for a network to scale effectively.
Two of the most popular scaling solutions right now include sharding and rollups (which are not mutually exclusive).
Sharding is the practice of splitting the chain into several “shard” chains which have their own block producers. Sharding lightens the load on individual block producers by splitting the processing power across shards. A full-node in a sharded chain will only run a full-node for some shards, and will run a light client for the remainder. This structure, however, may increase the risk of fraudulent or malicious node behavior, as shards have fewer block producers meaning an easier to gain majority. Fraud proofing and reliable data availability at the shard level thus remain important to this scaling technique.
Rollups are another scaling solution that employ either fraud or validity proofs (optimistic and zk rollups, respectively) to prove a block is valid. Rollups post blocks on Ethereum and thus circumvent management of data availability by using Ethereum as their data availability layer. Validity proofs are interesting because they don’t inherently require data availability, but the rollup itself still requires it in order to ensure users know the state of the chain and can interact with it.
Returning to the comment on the reliance on Ethereum as a rollup’s data availability layer, the Ethereum core protocol has a proposed sharding roadmap that would gradually expunge nodes of responsibility for historical block data storage (see: EIP-4444). Detaching data availability from the main chain poses interesting questions as to who owns transaction history data and how it is stored. Just as explored in many user data identity models, having reliable access to historical chain data is a critical component of ensuring an open and democratized system. For more reading on this matter, check out Vitalik’s notes here.
Scaling has been a problem at top of mind for many infrastructural developers, and conversations around protecting block verifiability to prevent malicious behavior continue to matter a lot. Actors on higher order systems and applications may be more commonly associated with “identity”, but at the end of the day the issues faced in scaling come back to the fundamental problem of protecting the network from vulnerability and deception. Fraud protection in decentralized networks is a pivotal component of identity establishment, whether at the individual network node or individual DAO contributor level.
Contractual identity is something not often discussed but is an incredibly interesting and uniquely web3 facet of identity representation. As alluded to briefly before, identity-bearing agents are not, by necessity, humans or even groups of humans. As we explored in our discussion of transactional identities, in several cases all transaction-handling addresses are viewed and honored as distinct identities. The interesting thing here is that smart contracts themselves have addresses and the ability to respond to and initiate transactions. Through this lens, contracts can be seen as transactional agents with whom both individuals and other contracts may interact. Figuring out how to establish contractual identity and where it falls on the spectrum of verification, validation, and contributor status will only become increasingly important as contractual autonomy and complexity increase in size and scale. Contractual identity is also a topic of discussion that may eventually come up in conversations around sybil-resistance. Some questions that I have had in this regard:
I think there is a compelling argument to be made for establishing a contractual reputation system, which powers a credit score of sorts for contracts that goes beyond just auditing and takes into account transactional volume, transactor turnover, contract lifespan, etc.
One cannot discuss identity within web3, especially layered identity, without also discussing the role of DAOs and novel social dynamics. DAOs are built around the premise of decentralized systems of collaboration, contribution, and decision management.
The use of treasury funds, the proposal of new projects and initiatives, and any other critical organizational decisions are typically made via governance proposals. With governance acting as the core organizational and executional layer of DAO management, it is critical that contributor votes are accurate and properly represented. Some teams currently working on sybil-resistant governance mechanisms include Snapshot x OrangeDAO’s combined effort to instantiate reputation and identity-based voting powers, and Finnovant x GovernorDAO’s biometric proof-of-existence approach to enforcing unique, verified account ownership.
DAO tooling is a hot topic right now, but perhaps not the first thing that comes to mind when discussing web3 identity. The reason I bring it up is that DAOs introduce novel identity structures that require custom management tailored to their relational needs.
You may be familiar with the increasingly popular subDAO, team, working group, guild, and autonomous entity structures employed by larger DAOs. These are methods of delegating tasks, projects, and governance to smaller groups within the larger ecosystem to enable faster iteration, more effective communication, and better informed decision making. Calling back to our initial conversation around composable identity units - individual identity, social identity, and community identity - within well-delegated DAOs we can start to see examples of these identity units and how their unique behavioral and incentive models play out in real time.
One interesting example of this is the governance model for Yearn Finance’s yTeams. The majority of decision making power is held by individual yTeams, which are defined by yearn to be “small, autonomous groups of yearn contributors empowered by YFI holders to act independently in the best interest of yearn within a constrained domain of action and with enumerated, discrete decision-making powers.” Decision making is done at the yTeam level within the team’s respective domain of action, to be executed or vetoed for further review by operators of the multisig.
What we see starting to emerge in the DAO ecosystem is a landscape of contributors that doesn’t just map one contributor to one physical individual. As DAOs scale, identities become tied to subgroup affiliation and corresponding execution power. A DAO subgroup (or even a DAO itself) may have independent, character-distinguishing identity traits, the ability to make and act on decisions as a unit, and the ability to communicate and engage with other DAOs. DAO-to-DAO collaboration and intra-DAO team collaboration are excellent examples of the web3 realization of relational identity as it applies to unified groups. Exploring the underlying mechanisms and behavioral traits of these interactions will be critical in the development of effective DAO communication systems.
I am continuously learning, and doing my best to aggregate the most accurate and insightful information in the process, but there may be errors or inaccuracies in my work. I want this to be as reliable of a resource as possible for those interested, so please DM me @dommydoteth on twitter with feedback, suggestions, or corrections!
So much of this content was made possible by protocol whitepapers, articles, tweets, and publicly available meta-analyses. If decentralized identity is a topic as interesting to you as it is to me, check out some of the resources I used below for further reading: