原文标题：《A&TView：DID赛道全网最详细梳理DID灵魂三问》
原文作者：林川，A&TCapital高级分析师
关于DID的讨论随处可见，但DID的概念似乎有些宽泛、令人困惑；你是否期待有人能帮你把DID这件事给梳理清楚？那就请不要错过本文！
摘要
DID现在一般是「去中心化身份」的简称，它是一种没有中心化机构做最终担保的数字身份，是Web2「用户画像」概念在Web3的延伸和拓展。
DID相关的赛道主要分应用场景、身份、凭证三层。凭证层是DID的构成组件，身份层是DID的具体形态，应用场景层是DID的价值体现。
DID发展的最终形态，可能是每个用户都有一个唯一的全网身份，和多个细分场景的局部身份。用户通过域名来记忆、标识DID，通过钱包来管理DID并和应用项目交互，通过钱包集成内的各种协议整合多条链上的不同凭证和局部身份。
DID当前并不是用户的直接需求，而更多是应用场景项目方的需求。
DID发展尚处于萌芽期，并且迭代较为缓慢，至今未有DID体系能积累起一定的网络效应；这主要缘于当前Web3非金融类应用项目发展的艰难。
DID一级投资的整体逻辑：从用户出发，应用先于协议。
前言：DID，一个被泛用、甚至滥用的概念
DID，是一个Web3领域的热门概念。在Twitter上，几乎每周都有讨论DID的TwitterSpace；在线下的各种Web3分享会中，DID也是经久不衰的热门主题之一；在项目的融资deck上，无论是社交、GameFi、DeFi、NFT等应用类项目，还是钱包、域名甚至公链等infra/中间件类项目，都可能会把DID加入其叙事之中。
然而，如此高的热度，不免的让DID这个词被泛用、甚至被滥用：
在最初的时候，DID的全称是「DecentralizedIndentifiers」，直译「去中心化标识符」。它是最具影响力的国际互联网技术标准机构「万维网联盟」，出于对Web2中心化身份体系的担忧，而牵头制定的一套标准。这个DID的概念，一开始和区块链/Web3其实没有直接的相关性，但如果你直接搜「DID」，依然能够看到不少文章所谈论的DID是这个具体的标准
而在现在的Web3交流中，DID更多时候被看作是「DecentralizedIdentity」的简称，也就是泛指「去中心化身份」。然而，去中心化身份本身也是一个缺乏明确定义的词汇，虽然初看每个人都能理解它大概的意思，但在不同场景下具体指的事情可能很不一样；而且在Web3的世界里，似乎做什么事情都能和它扯上关系。这也是为什么目前有关DID的讨论中概念较为混乱的原因。
本文接下来所讨论的DID，将采用后者「去中心化数字身份」的概念，并将以DIDs代指W3C的DecentralizedIndentifiers标准以避免混淆。
本文分上篇和下篇。在上篇中，笔者将分应用场景层、身份层、数据层，对DID赛道做一个系统性的梳理，以帮读者理解各种概念之间的区别和联系；在下篇中，笔者将阐述一些有关DID赛道未来发展和早期投资的一些主观看法，以抛砖、供读者思考交流。
上篇：去中心化身份赛道全景解读
在Web2，数字身份以平台为中心，同一集团内的不同产品间通过账号系统打通。例如，腾讯的邮箱、游戏、金融等皆可使用同一账号；Google、Facebook等互联网头部企业也均有自己的账号体系。这种身份体系虽然构建方便，但它的弊病也已经广为人知：平台相互之间的账号并不互通，以及用户没办法控制自己的身份数据。
在当前的Web3，用户的交互主要基于钱包地址，因此围绕地址的一系列活动构成了Web3最原生的数字身份。但是创建新地址的成本几乎可以忽略不计，也少有人会把自己绑定在一个地址上。这就导致了用户可以随时放弃一个地址所代表的「身份」，也可以零成本创建大量的地址「身份」，进而导致限制了这种数字身份的应用场景。
DID希望解决的问题，就是在去中心化的数字世界里，构建起对一个人身份的描绘。
一、DID的应用场景：假如我们已经有了一套成熟的DID……
DID是一个抽象的概念，为了更好的对它有一个直观的理解，让我们先屏蔽有关DID如何实现的细节，从应用场景出发：如果当前在Web3世界里已经有了一套成熟的DID，它能做些什么？
笔者把DID在应用场景层的叙事，大致分为两大类：Reputation和Relationship。
它们的主要区分方法，是假设如果你准备放弃你现有的「数字身份」，你能否在较短的时间内来重建一个可以代表你的新的身份？
如果是前者，那就是Reputation类；如果是后者，那就是Relationship类。
1.1Reputation：声誉/简历/社交展示面
Haru Invest：由于未完全确定B&S可收回资产规模，计划利用公司内部资产进行补偿:7月14日消息，Haru Invest发文称，由于尚未完全确定B&S Holdings持有的可收回资产的具体规模，目前很难追偿，因此正在考虑利用公司内部资产进行补偿，以防 B&S 持有的资产回收需要更长的时间。为此，Haru Invest正在整理债权债务数据库，并审查资产分配方案。同时，Haru Invest表示，需要为每个产品制定一个补偿计划。
目前，团队在暂停存取款服务后，暂停了所有运营，限制了对公司资产和账户的访问，并终止了全体员工的合同，以防止与B&S持有的资产和数据相关的损坏和丢失，并最大限度地降低运营成本以保护客户资产的损失。此外，由于客户资产金额是根据上个月暂停存取款后数据库中的特定时间点确定的，因此，如有系统错误或额外交易，如赚取收益等，团队将提前告知用户，未来付款可能不会纳入客户资产数据库。
本周开始，Haru Invenst 准备组织数据库来识别客户债权与债务、组织和保存退回的资产、制定资产分配计划。[2023/7/15 10:56:11]
这类应用场景，侧重于通过将数字身份简化为一些显性的可信标签，来对用户进行评价和分类，从而达到一个快速筛选的效果。这里举三个具体的相关例子：信用借贷、求职招聘、陌生人社交：
Web3信用借贷，希望能给用户账户地址打一个「信用分」，从而推算在信用借贷中质押可减免的额度。这种信用分，可以通过链下身份/资产证明来完成，也可以结合用户链上地址过往操作记录的分析。
Web3求职招聘，希望能够在链上生成一个用户的简历，以便用户快速向Web3项目方/DAO/社区等证明自己的能力，降低Web3求职招聘过程中的信息摩擦。简历中的工作经验、Web3能力等认证，可以通过链上地址分析、前东家的多签钱包地址签名、Web2公司邮箱认证等方式去完成。
Web3陌生人社交，希望快速构建对一个用户的标签描述。这种标签的描述可以取决于NFT的持有，例如BAYC的持有者可以被贴上「富有」的标签，各种兴趣类、社区类NFT的持有者也可以被打上对应的标签。用户可以把这些标签整合起来，放到自己的社交主页上去做展示；用户也可以根据这些标签快速筛选自己希望社交的对象、并对其兴趣偏好有一定初步的了解。
1.2Relationship：DID的关系类应用场景叙事
这类应用场景，侧重于通过将数字身份视为用户在Web3数据的累积，来做一些更加复杂、综合的应用分析。这里举四个具体的相关例子：
Web3推荐系统，希望通过用户的Web3相关数据的累积，形成用户画像，再对此展开针对性的个性化推荐、广告展示等。这套用户画像的叙事，其实继承自移动互联网时代平台大厂的核心逻辑，已经被证明可行。并且在Web3中，不仅身份数据可以跨平台互通，用户也能拥有自身身份数据的所有权、开放共享权，这样构建的用户画像体系可能会比Web2更加用户友好。
Web3熟人社交，希望通过用户在Web3社交互动的累积，形成一套用户的社交图谱，这种社交图谱可以被各种新的App所通用。这样，用户在使用新应用、进入新游戏的时候，就可以快速找到自己的熟人好友，而不必像Web2那样得自己重新加回来。
Web3游戏，希望构建一套游戏账户系统，通过用户在Web3游戏数据的积累，来刻画用户在游戏方面的兴趣和能力。例如，A用户可能在某几个Web3卡牌类游戏都有非常早期的参与记录，那么这些都可以被记录在GameID里面，这样如果新的卡牌游戏想寻找早期用户，就可以优先考虑A这样的人。
DAO投票治理，有时候会希望进行」一人一票」的公平投票。但是如何证明一个人只投一次票，而非注册多个账户来刷票，是一个难题。通过对用户地址历史记录的分析或者真人认证，就可以解决这个问题。
1.3两类应用场景之间的联系：由点到面，再由面到点
其实，Reputation和Relationship类应用的关系并没有那么泾渭分明，更多的是一种网状交错的关系。
更准确的说，各种显性的可信标签像是「点」，随着时间的推移，这些点围绕着同一个身份不断累计，最终生成了有关用户画像的完整的「面」；当用户或者项目方真的要利用这个「面」的时候，也需要进行进一步的加工，把它简化为几个易于描述和理解的「点」。
例如就NFT持有这件事情，在初期的时候，可能对一个用户只能打上BAYC持有者、Azuki持有者等标签；但随着时间的推移，如果我们发现每当有热门NFT出现，这个用户都会去参与交易，那么我们就可以做一个归纳分析，给他打上「热门NFT交易者」的标签。
以上，基本上是所有DID在应用场景层面叙事的一个归纳总结。可以看出，它基本上涵盖了几乎所有Web3应用层的叙事，这也是为什么DID也被称为Web3应用的「身份基础设施」。
二、原始数据形式和凭证：构成DID的各个属性究竟从何而来
Messari创始人：由于证券法限制，Genesis和DCG的GBTC清算无法形成“抛压”:金色财经报道，Messari创始人Ryan Selkis在社交媒体发文称，DCG和Genesis无法“抛售（dump）”GBTC，而这也是其流动性危机的一部分，尽管对GBTC和焦虑的投资者来说是个好消息，因为公共市场有规则可寻。自2021年初溢价转为折价以来，DCG购买了价值近8亿美元的GBTC股份，DCG董事会授权Grayscale Trusts购买高达12亿美元的GBTC股票。二季度，DCG/Genesis将3500万股GBTC（占比约5%）作为三箭资本的一部分抵押品，DCG及其附属公司现在拥有10%的信托股份，但这部分股份的流动性现在已经变得极差，因为灰度不是真正的“ETF”，只是根据 144 规则公开上市的工具，其日交易量只有450万股，未来或许会使用GBTC作为抵押品进行DCG-Genesis再融资。[2022/11/28 21:07:55]
可能读者已经感觉到了，在上述不同的应用场景叙事之中，每个数字身份具体指代的东西其实不太一样，但它们都可以被称作「DID」。这里面，其实主要有两个关键问题：
这个「去中心化身份」，它是由哪些具体的标签/属性/凭证组成的？比如，它希望连接的，是用户的NFT持有、链上交互记录，还是用户的社交关系，抑或是用户在链下的身份信息？
这个「去中心化身份」，它是聚合在哪个标识符之上的，或者是说面向外界交互的主要接口是什么？比如，我们是用一个NFT、一个地址、还是一个域名来代表某个身份?我们怎么拿一个身份来和应用方互动？
理清楚这两个问题，就能看清楚在DID在身份层纷繁复杂的各类项目。
让我们先来思考第一个问题，即，构成DID的各个属性究竟从何而来。
2.1凭证：为什么对于去中心化身份很重要？
先看以下例子：你新认识了一个人，他说「我是张三，1990年出生，本科毕业于北京大学，和你的父亲很熟」。他有求于你，但是你因为某些原因，对他的自我介绍内容抱有极大的不信任。那他应该怎么向你证明他所说的事情的真实性呢？
如果他想证明他的姓名、年龄，他可以出示他的身份证，甚至可以和你一起去派出所走一趟来证明这身份证是他本人；如果他想证明他的学历，他可以出示他的毕业证书，或者是给你发个学信网的证明；如果他想证明他和你的父亲很熟，他可以联系你父亲来找你说明。反过来说，如果他有求于你、很想证明自己的身份，但当你希望他提供上述的具体凭证的时候他却无法提供，那么你就有足够的理由去怀疑他陈述的真实性。
因此我们可以看到，一个身份，是由许多个属性组成的，例如刚才张三对自己的陈述中，所涉及的姓名、出生年、学历、社交圈等属性。但是，如果没有相应具体的凭证，这些属性是没有可信度的，而多数应用场景不会去采纳一个没有可信度的数字身份。由于在Web3中，一个身份的属性来源更加多样、潜在使用方更加广阔，难以找到一个中心化的总担保方，因此对每个属性的凭证验证就显得更加突出。
2.2凭证原始数据来源的分类
所以，当我们在研究一个DID的具体构成的时候，其实我们关注的就是具体的凭证。
用户的链上数据，由于区块链底层的不可篡改特性，是最天然、直观的凭证数据来源。甚至这种信任，可以只基于底层公链，而不需要具体的凭证发行方。比如，要证明钱包地址A确实向钱包地址B转过钱，只需查对应的链上信息即可。这种没有凭证发行方的信任，是其它几种凭证数据来源所不具备的，也是区块链的核心魅力之一。有不少Web3的工具类产品，做的就是链上数据的整合分析。
不过，在目前的Web3世界中，链上数据主要以转账、DeFi交互、NFT交易/持有为主，它所能带来的身份信息是有局限性的。然而在现实世界中，很多时候我们信任一个凭证的前提，都是信任一个凭证的发行方，而这种信任关系的构建却是在Web2或者是现实世界之中的。很多时候，我们很难把整个验证过程完全放到链上，例如驾驶证——即使再怎么数字化，考试本身还是发生在现实世界之中的。
当前，将Web2、现实世界中的数据和信任关系做成可信的凭证的形式，主要有以下三种：SBT、VC、PoP。
2.2.1灵魂绑定代币
SBT(SoulBoundToken)，即灵魂绑定代币，是2022年5月Vitalik等人在发布的「DecentralizedSociety」一文中所阐述的新概念。
由于SBT目前并没有一个通用的明确标准，其实现在的SBT可以被简单理解为Non-TransferrableToken，即「不可转让的代币」。事实上，以这种代币为形式的凭证早就存在了，比如POAP、ProjectGalaxy所颁发的凭证。
SBT的实现是最为简单的，也天然具备非常好的互通性、公开性。并且，由于SBT是链上原生的，它也可以作为一个链上数据分析方法的「结果凭证」，比如链上信用评分。
由于以太坊Gas价格 合成资产平台Public Mint推迟其IDO:据官方消息，合成资产平台Public Mint表示，由于以太坊的Gas价格会对参与IDO的参与者产生负面影响，与Plkastarter协商推迟了IDO。官方表示，将在未来24小时内宣布一个新的IDO时间表。[2021/2/23 17:45:20]
SBT主要的问题在于其公开性所引起的用户隐私相关问题。SBT的公开性使任何人都可以轻易地对一个人进行关联和推断，而且可能让隐私无从遁形，并刺激了某些形式的歧视。例如，一个有种族主义倾向的雇主，可能会因为偷看求职者的钱包显示其参加过黑人生命关怀组织活动，而对潜在雇员产生歧视。
理论上，通过ZK技术和SBT的结合，可以实现用户的隐私保护。但这不仅涉及到具体的技术实现上的一些难点，也可能会影响到SBT的公开性和互通性。
2.2.2可验证证书
VerifiableCredentials，直译「可验证证书」。
在本文的开头有提到，最早在没有区块链的时候，就有一些人开始思考数字世界的去中心化身份问题了，VC也是W3C提出的概念、标准体系内的一部分。
让我们通过下面这个跨国驾照认证的例子来直观理解VC：
假如一个德国人Hans获得了驾照，那么就可以向申请德国官方，用其去中心化标识符来颁发并签名一个VC。这个VC以数字文档的形式存在，是Hans取得驾驶证的凭证，由Hans自己保存。
如果Hans到澳大利亚并开始自驾游，需要出示自己的驾照时，他就可以向澳大利亚政府出示他从德国官方这里拿到的VC；澳大利亚官方在看到了这个经过德国官方ID签名过的数字文档以及上面的信息之后，就可以认为Hans具备驾驶的能力。
虽然，严格意义上VC的具体撰写有一套W3C定义的标准，里面的去中心化标识符也是W3C体系内的DIDs。但从Web3的视角来看，广义上用钱包地址去代替这个去中心化标识符，在基本逻辑上是行的通的，下图就展示了用户、VC发行方、VC验证方之间的关系：
可以看出，VC相比于SBT，其主要优势在于对用户隐私的保护，用户可以天然的对自身的信息进行可选择性披露。并且，它的实现可以和区块链技术无关，也就是对于Web2也有很好的兼容性。
VC的主要问题，在于它本身虽然有一套相对公认的标准，但这套标准需要DIDs做支撑，而DIDs的推进相对缓慢。如果项目方或者Web3社区要自己定一套VC的运作流程标准，那么怎么去推广这条标准，也会是一个难点。
2.2.3人格证明
人格证明，主要做的事情通过同链下真人信息绑定的方式，来证明数字身份的唯一性。ProofofHumanity，BrightID，和IDENA，都是其中的代表项目。
具体的实现，主要通过KYC和视频人脸识别两种技术。KYC是交易所盛行的经典认证方式，通过KYC，一个数字身份就会和你在链下的法律实体信息绑定；人脸识别，如BrightID，主要将你的人脸信息录入数据库中，确保在一个项目ID系统里面一个人只能注册一个ID。
可以看出，PoP类认证在当前最直接的应用场景是抗女巫攻击。另外，在各国都在考虑加密货币监管的大背景下，KYC有可能会成为一个「合法身份」组建的必要条件。
2.3凭证类的相关项目
可以看出，虽然去中心化数字身份的具体构成可能很复杂，但归根到底，主要由以下四大类凭证构成：链上原始数据、SBT、VC、PoP。
严格意义上，SBT也是链上原始数据的一部分，但SBT一定是通过某种方法再次加工过的，并且其信任可能依赖于发行方；而对链上原始数据的信任只需要基于对底层公链的信任。
和凭证相关的具体Web3项目又有哪些类型呢？
多数情况下，许多凭证的认证规则有很高的互通性，比如说验证用户是否在链上完成一笔交易，验证用户是否帮忙转发了项目方的Twitter，或者说验证这个用户背后的真人是不是第一次尝试获取凭证。在这个背景下，凭证的发布方本身并不需要做一套发布凭证的工具。
因此这个细分领域不少的项目类型，其实是凭证发布的工具/平台。以ProjectGalaxy为例，项目方可以在ProjectGalaxy上发布任务，用户可以通过在平台上完成任务并做认证后，获取项目方发放的凭证。
但在一些复杂的情况下，凭证的发布方希望自己设计规则来给用户进行认证，特别是在一些较为复杂、评价存在一定主观性的场景。之前提到的人格证明类凭证，也可以归为凭证发布类的项目。
其它的例子如：
Rabbithole是「学习认证」类项目的代表，它提供各种Web3称号的认证，这些就需要用户完成较为复杂的任务；某种程度上，这里面的逻辑和在线网课的结业证书很像，Rabbithole也可以说是「Web3在线教育」的一种雏形。
ARCx希望根据每个DeFiPassport持有者的信用分来量化其链上地址的信誉度。信用分将通过分析持有者的以太坊地址历史活动来确定，其范围设置为0到999分，该信用分确定了协议为用户提供的抵押率。对于信用分高的地址而言，DeFiPassport能够提供有竞争力的借贷抵押。
FirstBatch希望通过读取用户在Web2社交媒体的授权数据，用AI在链上生成用户的兴趣标签，并用ZK技术进行隐私保护。
三、身份层：应用场景和凭证的连接，具体的DID形态
我们已经讨论了DID具体的应用场景，也讨论了DID身份的具体构成——凭证。而将应用场景和凭证连接起来的，就是身份层项目所做的事情。例如，域名、钱包、社交图谱、地址关联分析……
如何区分一个项目到底是不是在做身份聚合？这里笔者提出一个判断方法：如果一个项目做的事情，既没有在具体面向用户的场景里面用到DID，也没有给用户生成新的凭证，主要做的事情是各种「绑定」和「连接」，那么它大概率就是身份聚合层的项目。
但是怎么做一个Web3的身份聚合，不同类型的项目给出了不一样的路径和思考方式。它们大体可以分为两大类：对链上原始数据、各种凭证的加工聚合，以及面向用户、帮助用户实现数据主权的身份管理工具。
3.1信息聚合协议
用户的链上数据，往往分散在多条公链、多个项目智能合约之内，因此需要把它们经过加工和聚合以后才能形成一个身份。许多项目，做的就是这样的一个信息聚合的协议。
这些协议，往往没有直接面向用户的产品，它们主要是面向项目方和其它协议的，可以相互之间进行合作于信息聚合。举例如下：
Cyberconnect希望做一个链上社交图谱，聚合用户的社交关系数据
KNN3Network希望通过对Footprints关联分析、Cyberconnect等其它社交图谱的整合，来构建在多条链上的用户社交关系图谱
RSS3希望做一个链上的内容和社交信息的聚合，之后可能会往Web3的信息分发、推荐系统方向发展
而下面几类身份管理工具类项目，都希望给用户提供主动的身份管理能力，是用户实现数据主权的直接工具。
3.2身份管理工具-钱包
钱包直接面向用户，是当前公认的「Web3入口」。虽然它本身不太能说是一个DID的应用场景，但它是一个天然的连接应用场景和用户所持凭证的通道。
一个理想的「DID钱包」可能是这样的：首先，它能够聚合所有主流公链的地址，在具备基本签名、转账等交易的同时，整合用户在不同链上碎片化的数据；其次，它能够显示用户所拥有的各种SBT/VC/PoP凭证，在和应用项目交互的时候，用户可以自主授权向项目披露哪些数据，从而帮助用户实现数据主权。不少钱包都会提到DID的叙事，如Unipass，ABTWallet，Selfkey等。
不过，当前主流的Metamask等钱包并不具备这些功能。一个重要原因是，它们基本都是EOA钱包，而这类钱包基本只支持链上地址最原生的操作——查询和转账。而智能合约钱包，有望在钱包功能上实现更多的扩展。DID钱包相关的技术落地其实有不少挑战，不过也非常值得我们期待。
3.3身份管理工具-域名
虽然我们每个人都有一个独一无二的身份证号，但在日常生活中，我们一般会用「姓名」来作为一个人身份的标识符，因为它更便于日常交流。
Web3的世界，同样也有这样的问题：虽然人们目前的交互主要基于钱包地址，但没人会愿意记那一长串字符串。如果说Web3的数字身份需要一个「姓名」，那么域名类项目所做的事情，就是希望成为这个「姓名」。
ENS是域名中知名度最高的项目，它有以太坊基金会的官方支持，提供.eth后缀域名的注册服务，现在已经有了近180万的注册量。值得注意的是，SpruceID在和ENS合作，在推进EIP-4361:SignInWithEthereum。如果该项提案顺利实施，这将取代ConnectWallet，让域名于钱包地址之上、成为Web3的入口。另外，ENS也希望通过域名中一系列身份的整合，来完成自己「Web3姓名」的愿景。
另一个值得关注的域名项目是SpaceID，它有币安官方的支持，提供.bnb后缀域名的注册服务。SpaceID也希望将.bnb域名与用户在不同链上的多个地址，用户的Twitter等Web2账户进行id，成为一个Web3领域的Universalname。相比于ENS，SpaceID的产品迭代速度和落地速度会显得更快。
除了ENS和SpaceID以外.bit、UnstoppableDomain近期也完成了较大额的融资。它们讲的和DID相关的叙事，基本上大同小异。
值得注意的是，域名和钱包虽然都可以作为身份管理工具，但它们在角色定位上是很不一样的。它们在理论上并不冲突，而是可以紧密合作：钱包可以用一个域名作为钱包账户名的替代，并将其作为和应用方交互时的「姓名」；域名也可以整合多个链上地址甚至多个钱包账户。
3.4其它身份管理工具-以Next.ID为例
也有一些身份管理类产品，对身份管理实现的具体理解有别于之前的几类项目，但做的事情核心主要也是各种连接和聚合，并且不局限于特定领域，希望做一个全网身份的整合。下面以Next.ID为例，这是MaskNetwork做的一个身份管理类的新产品。
和不面向用户的身份聚合protocol项目不同，Next.ID是一个面向用户的产品。在V1版本中，用户可以通过MaskNetwork，来实现Web2各平台账号、Web3各公链钱包地址的连接和聚合，并且能够做主动的身份管理；相比于域名和DIDs，可以说Next.ID也是在做一个统一数字身份层面的聚合，并没有强调一个显性的标识符，而是希望在聚合身份之后将其做成一个基础设施，供App调用。假如Next.ID之后开始推广自己的域名，或者是推广Mask账户用户名等标识符，那么它做的事情和SpaceID、ENS等域名项目就会有一定的重合度了。
但除了用户侧的聚合以外，开发者可以通过Next.ID的Avatar体系，实现将自己产品中用户账号之间的具体操作和Next.ID互通，如下图所示；它在一定程度上可以做很多身份聚合类的protocol想做的事情，也可以选择和这些protocol合作，将它们再做聚合。
来源：Next.ID官方文档
3.5局部场景身份管理工具
3.5.1GameID
除了一些希望做一个用户全网数据大聚合的身份管理工具项目以外，也有一些基于局部场景打造身份管理工具的项目。
比较好理解的例子，是聚合用户各种链上游戏信息的GameID，如去年比较火爆的Loots。
GameID里面的ID，更多是指在一个生态系统内部互通的账号体系，类似于Web2中盛大账号、QQ号，它们只想做用户在这个生态系统内部的特征描绘，并不是想做一个代表用户全网数字身份的大聚合。
因此，与其说它是DID，不如所说它是用户DID的一个局部碎片、一块拼图。
例如，张三注册了域名zhangsan.eth，他的「盛大」ID是123456，里面有5个来自不同「盛大系」游戏项目的凭证；他的「腾讯」ID是567890，里面有9个来自「腾讯系」游戏项目的凭证。那么虽然「盛大」和「腾讯」可能都有一个专门的身份管理工具帮助用户管理对应的平台账户，但在它们都可以被zhangsan.eth这个「Web3姓名」所聚合，成为zhangsan.eth身份的一个标签。
3.5.2DIDs
经过多年的研究和讨论，W3C终于在2022年7月推出了去中心化标识符的v1.0正式标准。作为「DID」最初的定义，理清楚W3C的DIDs和现在的Web3DID体系之间的关系，也是有必要的。
W3C标准的去中心化标识符架构中，用户直接控制着标识符和对应的文档。APP能够在用户许可下读取DID链接的文档从而实现业务，文档中包含了数字身份相关信息，如签名、加密数据等等。用户通过加密签名证明对DID的所有权。用户的数据存储在可信的数据库内，身份数据并不依赖APP。
DIDs有三个组成元素，如下图所示：DIDscheme，类似于http、ipfs等方法声明；DIDMethod，是一个具体方法的标识符，每一个想建DIDs身份体系的项目都可以去申请一个，例如腾讯可以为QQ申请一个tencentqq的标识符；DIDMethod-SpecificIdentifier，是一个具体的id，它有什么用取决于具体项目方的定义，例如腾讯可以用did:tencentqq:123456789来指代你的QQ号123456789。
DIDs的详细运作流程和技术细节，相对复杂，这里就不展开详细介绍了。
DIDs某种程度上和Web3域名是竞争关系，这里把DIDs和域名的主要区别做个对比：
在可读性上，DIDs相比于域名而言更缺少用户层面的可读性，但由于DIDMethod的存在，它可以多带一层语义、有更好的灵活性
在信息聚合的潜力上，DIDs加上与之配套的VC等验证方法，理论上可以聚合更多链下信息，特别是权威机构提供的数字凭证；而目前域名类项目的数据聚合还是以链上信息为主，如果要更好的链下信息聚合，可能需要与之配套的VC标准
在数据存储上，DIDs的数据存储并未指明，可以直接存在公链上，也可以存在一些去中心化数据网络上，甚至也可以直接给用户自己存储；域名类项目的数据存储都是在链上的
总体而言，DIDs这套体系，是一个自上而下设计的，更全面、兼容性更好的标准。也有不少采用DIDs路线去实现数字身份的项目，如Ontology。
但是，DIDs的用户可读性缺失问题，长期来看很难成为用户日常生活中记忆的「Web3姓名」，再加上用户在不同的DIDMethod里面可以有不同的DIDs，使得DIDs从长期来看可能会是一个被域名所聚合的对象，因此可以将它称为「细分场景/局部身份管理的标识符」。另外，虽然理论上DIDs对链下信息有很好的兼容性，但出于利益考虑，当前Web2公司鲜有基于DIDs做相关的推荐，DIDs如何推广也是个问题。
3.6身份管理工具：全网身份vs局部身份
GameID、DIDs的这种局部身份聚合特点，也引出了对身份管理的总体性和局部性的思考：
如果你的身份管理产品不能、或者做不到对用户全网数字身份产品的聚合，也就是没有成为用户的「Web3姓名」，那么由于链上数据的互通性，你的ID可能就会成为那些更大的身份管理产品的一部分。例如，小的GameID被大的GameID聚合，GameID被.eth域名所聚合，甚至.eth域名也可以被.bnb域名聚合。前文提到的DIDs，之后也很可能会成为这种「局部身份」。甚至某种程度上，单个钱包地址也可以说是一个「局部身份」。
不过，局部身份管理工具也有其存在的价值，因为它可以就具体的应用场景打造更多功能，而这是全网身份管理工具不一定会做的，不然它就会变的臃肿。比如，在一个GameID管理平台里面，用户可能可以根据其它GameID的信息展示，来交同一个MMORPG内相同魔法职业的玩家为好友，但如果一个钱包/域名项目要做多个那么细分的功能，就会提高产品的复杂度，从而面临许多产品设计上的挑战。
四、对DID未来发展的终极形态的思考
首先，未来每一个人都会有一个与个人日常生活深度绑定的数字身份：
这个DID每个人只能有一个，通行于Web3全网，甚至可能通过KYC等方式和用户的现实身份所绑定，从而更好的和链下世界所互动。
Web3域名，是这个DID的唯一标识符，也就是用户在Web3的名字。
用户通过一种功能远比现在强大的多的钱包，来管理这个DID；在钱包内部，可能集成了多个身份聚合协议，来实现用户多地址、多合约的数据聚合，全面的展现用户在各条链、各个地址上的凭证、局部身份、关系图谱等，作为一个整体用户画像。
用户通过钱包，和社交、招聘、DAO治理等应用场景交互。通过加密技术，用户可以自主控制项目方获取数据的权限，从而实现数据主权归用户所有。
其次，每一个人在一些局部场景，或者是一些无需PoP的场景，拥有多个不同的数字身份，从而在不同的场景下展现不同的自我。用户可以自由控制这些身份之间的相互连接，在特定的场景使用对应的身份。
五、上篇总结
通过以上的梳理，希望以后当读者再看到一个项目在讲DID相关的叙事的时候，能清楚的知道这个「DID」指的是具体什么样的「去中心化身份」：是在讲某类具体凭证的发布，还是在讲各种凭证聚合为身份的过程，还是在讲用户对身份的管理，抑或是在讲这套身份体系的具体应用场景？
非常值得提的一点是，一个DID相关的项目往往会做不止一层；比如说，之前分析的Next.ID既向域名那样做用户侧的身份交互，也会向很多身份protocol那样做身份聚合；ARCx既准备做信用评分凭证的发布，也会做与之相关的应用。
下图是一个对DID相关赛道的梳理，作为上篇的收尾。
下篇：DID灵魂三问
在下篇中，笔者将通过三个问题，阐述一些自己对DID领域的思考理解：
DID现在究竟是谁的需求？
为什么DID还处于萌芽期，且发展缓慢？
DID赛道，应该怎么投？
一、DID，现在究竟是谁的需求？
1.1DID，现在不是用户的需求
通过之前的梳理，可能不少读者已经发现了，在很多情况下DID本身并不是用户的直接需求！从产品经理的视角来看，DID如果要面向用户，往往要通过具体的应用场景。
试想，如果你现在没有具体的应用需求，你有兴趣去主动获取各种凭证，或者到一些身份聚合/管理工具(比如Next.id)，把自己的邮箱、Twitter、各钱包地址都Connect起来么？相信大多数用户是不会的。
虽然如果项目方提供一定激励，也肯定能够吸引一些用户，但DID类产品的特性，决定了单纯靠这种激励本身难以带来用户的持续留存，这和NFT、GameFi等其它类别项目不太一样。
从长期来看，随着DID发展的逐渐健全，用户对个人身份数据的管理和利用的意识也会越来越高，那么有可能会出现对身份管理的需求先于具体应用场景的情形。但在DID赛道还处于萌芽期的当下，这是不太可能发生的。
1.2DID，是应用场景项目方的需求
其实，受益于DID更多的，还是具体应用场景的项目方。无论是基于凭证的快速筛选，还是快速获取用户在Web3的画像，都会给在冷启动阶段的项目方带来直接的增益。
不过，应用场景在真正用DID、构建DID的时候，未必要和用户强调DID这个概念，它是抽象在产品的逻辑之中的。所以，更多的时候DID这个概念出现于项目的叙事和大家的讨论中，而不是具体的应用场景中，也就不奇怪了。
二、为什么DID赛道还处于萌芽期，且发展缓慢？
公认的事实是：DID的概念可以追溯到Web2时代，从去年11月ENS发币后开始火爆，但现在DID赛道还处于萌芽期。虽然和DID相关的项目非常多，但至今DID的形态都还没有定论，也没有哪一个DID体系的数据积累已经有出现网络效应的迹象。
在理清楚DID的发展需要具体应用场景之后，不难理解这个问题：这和当前Web3发展的「超金融化」，非金融类Web3项目发展缓慢有关。当我们去看和DID叙事相关的应用场景的时候，可以发现几乎所有非金融类的Web3项目，都可以引入DID叙事。
因此，要回答这个问题，本质上是要回答为什么各个DID相关的Web3应用场景相关的赛道发展缓慢。
2.1Web3非金融类应用场景发展缓慢的三个原因
笔者认为下面三条逻辑，适用于所有的Web3非金融类应用场景类项目的分析，包括社交、游戏、招聘等。
Web3应用的用户体验，当下和对应的Web2应用差的很远。无论是产品的使用门槛、网络延迟还是操作费用，都高于Web2。
Web3应用的用户基数，远小于Web2，且分散在世界各地。这不仅阻碍了现实世界和链上世界的联通，也给网络效应的积累带来了更多的困难。
现在处于熊市周期，不少用户的资产亏损、链上活动频率降低，甚至也已经有些用户开始像2018年那样怀疑整个行业，直接「退圈」；这使得Web3应用类项目的启动更加艰难
上述这些每一条，都可能是一个Web3应用场景类项目难以发展的重要原因。那是不是Web3应用类项目就没有发展机会了呢？并不是。在一些Web3原生、Web2做不了的场景，即使有上面问题，相关的产品也能够体现出它的价值。
2.2ToC的信用借贷，中短期内是伪命题
信用借贷，是DID的应用场景中最金融化的。这也是一个经常出现的议题，因为现有的DeFi几乎都是超额质押，资本利用效率低，理论上信用借贷可以提高用户的资金利用效率，Web3用户对此也会有较强的需求。
然而，笔者认为，ToC信用借贷在中短期内，都是一个伪命题，或者是一个极其小众的领域。
最主要的原因，在于Web3世界并没有像Web2那样，对不偿还的贷款有追索机制。因此不偿还贷款的极限代价，是失去一套链上身份的可用性。
有人可能会说，数字身份本身也是值钱的，你可能不希望放弃你用了多年的地址、域名等身份标识，包括上面的各种凭证和关系数据的累积。但问题是，扪心自问，多数Web3用户当前的链上身份又能值多少钱？如果能够「信用贷款」100U，多少用户可能想着不还钱、宁愿重建身份？除非信用审核的门槛极高，但这也会让其变成一个极其小众的产品。
有人可能会说，如果做KYC、人脸识别，可能得以规避这个问题。然而事实上，在各不发达国家的乡村地区，不值钱的个人真实身份数据比比皆是。想一想大家日常看到的「某交易所KYC账号批量出售」等信息吧，只要「信用额度」高于一个身份的构建成本，就会出现职业的「养号」用户，批量构建满足要求的身份，然后不还贷款，薅项目方的羊毛。
ToC信用借贷的成熟，可能需要等待整个DID体系的成熟：一方面，随着各种高价值凭证和各种数据关系的积累，数字身份的构建成本、放弃门槛也会越来越高；另一方面，随着各国监管的渗透，Web3的贷款可能也会建立起法律追索机制，这会提高用户不还贷款的代价。
三、DID赛道一级投资的逻辑是什么？
在这里，笔者分享一部分个人对DID赛道一级投资的整体思考：
整体逻辑：从用户出发，应用先于协议
具体优先级：身份管理>应用场景>凭证发布>身份聚合protocol
3.1整体逻辑：从用户出发，应用先于协议
这里的「应用」，是广义的「面向用户」概念，包括具体场景、身份管理、凭证发布「协议」，泛指不直接面向用户的各种protocol产品，它们往往以API调用的形式，服务于应用项目方或者其他协议。
有一些协议项目方，可能是这样思考的：作为一个协议，我会不断的说服更多的应用项目方来接入我的协议，这些应用可能多数只是昙花一现，少数可能发展不错，但无论如何，我的数据都积累起来了，开始有了数据壁垒和网络效应；这样我的价值也越来越高，会有越来越多的应用层项目来找我合作；最后，我就可以对API收费，或者是提供相关增值服务。诚然，上述逻辑是有已经道理的，也是有走通的可能性的。
但笔者主要出于以下原因，更偏向于应用优先：
首先，在数据的流向上，应用一定先行于协议，从而会有更大的主动权。协议与应用之争乍看有点像「先有鸡还是先有蛋」，但其实不是。因为前文已经论述过了，DID数据的积累，依赖于用户在具体应用场景的互动。
其次，协议项目方做的东西，可能并不成熟，还在概念/测试阶段；即使成熟了，也可能并不能很好的满足应用项目方的需求。应用方与其反馈给协议方、期待其迭代，不如自己做一个。
更现实一点来看，数据壁垒、网络效应这种如此优秀的、已经被Web2验证的叙事，在赛道发展的萌芽期，没有任何优秀、有野心的应用项目团队会主动放弃这个叙事，而把这种价值的捕获完全交给其他项目方做的协议。
毕竟，当前Web3应用类项目的融资本身就很艰难了，应用项目方为什么不自己把协议相关的DID叙事也讲了，来作为其估值支撑呢？比如，先通过应用本身吸引用户参与、积累数据，然后将用户在应用内的数据协议化，给相关的合作伙伴、生态系统使用，从而进一步积累数据，最终发展成为一个DID体系。这个叙事很多时候是完全讲的通的。
再加上多数DID的协议其实缺少技术壁垒，壁垒更多体现在一定的工程复杂度上；对于优秀的团队而言，在一开始就自研协议，难度不会很高；即使应用项目方初期为了产品快速迭代用了其它的协议，如果应用真的能够获得一定成功，项目方也可能会考虑自研协议，来提升项目的发展上限。
3.2具体值得关注的细分赛道
优先级：身份管理>应用场景≈凭证发布>身份聚合protocol
身份管理工具类的项目：以钱包、域名类项目为优先。毕竟在未来笔者对DID的终极形态构想中，这两者都占据着非常核心的位置。
应用场景类的项目：之前说到，更多的机会出现在Web3原生的应用需求、而不是Web2产品的复刻。基于凭证的Web3招聘，基于NFT的兴趣社交/异性社交等，都是属于这种不可替代的Web3场景。
凭证发布类项目：凭证发布工具/平台这块，可能会跑出1-2个头部的通用项目，和数个细分应用场景的相应工具；具体的凭证发布类项目如果能提供高价值的凭证，那也是值得关注的。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。