最近 DID（decentralized identity，去中心化身份）话题特别火，融资新闻也一个接一个。关于 DID 这个概念要如何理清却颇有争议，尽管处于这样的发展早期，很多理念并未完全明晰，不过对于一些已经出现的比较明显的困惑，我们有必要罗列出来，一起尝试看看，拨开 Web3 身份的技术迷雾。

1. 用户到底需要什么样的 DID，或者说什么样的 DID 体系;

2. Web2 的用户迁往 Web3 面临着什么样的迁移成本;

3. Web3 DID 能给用户带来什么在 Web2 中无法获得的东西。

据不完全披露，钱包领头羊 MetaMask 目前的月活用户数，起码是 3 千万以上的级别。这导致了大部分的 dApp，很自然的希望通过 MetaMask 来做身份层。而这个想法显然有非常多的挑战，毕竟 MetaMask 只是想做一个钱包而已。

先不论 MetaMask 有没有动机和动力，愿意维护这样海量级别的公共 API 来给 dApp 调用。一个始终绕不过去的，横亘在用户面前的大难题是：作为 EOA 类（externally owned address，外部所有者账户）钱包，只要我的私钥或者助记词丢失，我将丢失我对应账户里的所有资产。

只要 MetaMask 类的钱包无法解决这个巨大痛点，Web2 用户很难突然有勇气跳入 Web3 的兔子洞。

那 Web2 的用户目前是什么样的体验呢？

如果我们做一个简单比喻，把 Web2 里的姓名和身份证号（或者驾照、护照）这样的唯一 ID，分别对应于 Web3 的公钥地址和私钥。

可以发现，第一个问题：一个 Web2 用户即使丢失了身份证，即类比于私钥，Ta 依然可以通过中心化的认证机构之一国家公安机关，来重新申请一个身份证。Ta 的对应资产不会丢失。

以此类推，Web3 同样需要做到：私钥丢失后，我能不能通过去中心化的认证网络，通过什么样的方式来恢复对这个账户的控制呢？如果这个目标达成，在这一点上，Web2 用户迁移 Web3 的成本为零。

那么第二个问题：我有 MetaMask 钱包，我有币安等各类交易所的钱包，我还有各种 dApp 服务给我默认生成的钱包。这么多私钥，这么多助记词，我们是不是要等 Web3 重造一个去中心化版本的 1Password 或者 LastPass 来进行托管呢？用户成本大大增加，要去添加、管理所有的可能未来长到没有尽头的账户列表。简直要命。

所以问题出在哪里呢？让我们一起回到 Web2 世界想一想，就清楚了。

MetaMask 这样的钱包，本质上是一个银行户头，就好像我们在中国工商银行、花旗银行等等的账户，从而可以进行金融交易。我们只能使用身份证号（或者驾照、护照）这样的唯一 ID，去开一个新的银行开户。那如果我们持有中国工商银行的户头，去中国建设银行要求开户，可想而知一定会被工作人员请出去。

因为“身份”与“银行户头”，并不能直接画上等号。

并不止 Next.ID 社区持有这个观点，很多社区和 DID 产品也都这样认为，比如以太坊社区通过提案 EIP-2938，正式提出抽象账户（abstracted account），以此开发智能合约钱包。另一个很受欢迎的 DID 新产品 UniPass 也是采取类似思路。

也就是说，通过身份（公私钥对）与银行户头（抽象账户，钱包地址）的解耦，尝试建立一些全新的机制，我们得到前述难题的解法：

1. 私钥丢失不代表资产丢失，我可以用新的私钥去绑定已经丢失私钥的资产。

   1. 方式一，社交恢复（social recovery），通过过去已建立联系、链上留下高质量互动记录的好朋友们，给你进行担保的方式；

   2. 方式二，可以使用一系列等价于私钥级别的隐私安全问题，来辅助恢复账号。比如我小时候的宠物叫什么名字/我高中的英文老师是谁等等；

2. 所有相关抽象账户（Web2 IDs、Web3 抽象账户）的管理，可以直接绑定、收归到某一个数字身份（公私钥对）进行管理，在 Next.ID 里我们称之为数字化身 Avatar。神作电影《阿凡达》记得吧？半身不遂的人类 Jake 通过神经连接，控制着一个纳美星男性健全的身躯。是不是很像我们未来控制一个元宇宙里的数字化身？如示意图：

好的，到这里为止，我们算是把「定义 DID 身份的最底层是公私钥对」这一层说了个大概。当然了，作为 DID 的私钥管理问题，仍然有待整个 Web3 社区一起去探索，在未来通过社交恢复以及等同于密钥等级的个人隐私问答等等方案，一起来降低使用门槛。

前一阵，Tornado Cash 所带来的监管风暴，让很多 Web3 从业者感到后怕。直接查封地址，甚至还会连带封杀所有与之有过交易记录的地址，这种“满门抄斩株连九族”的做法令人不禁对 Web3 的抗审查性产生怀疑，信仰动摇。

与此同时，市面上很多 DID 项目做的就是粗暴的聚合服务，也不管是否链上链下账户，会不会有泄漏个人信息的风险，统统放到一起。那是不是等于说，在 zero knowledage proof（零知识证明）等隐私保护技术尚未完全成熟的今天，我们直接把自己拱手交出，好让监管部门一网打尽？

颇为尴尬。

有没有可能 DID 项目都太照顾项目方需求、反而忽视了用户的真正需求？

如果从用户角度出发，一个 DID 系统整体的落地方案，不仅包含前一小节我们谈到的「定义 DID 身份的最底层是公私钥对」，还至少包括往上的两个层面：

• 第二层面，在这套方案中，随意一个 DID 身份能够安全地满足，所有前来访问需要授权信息的 dApps 的并发调用流量，同时提供媲美 Web2 的 OpenID/OAuth 一样的丝滑体验，用户操作”傻瓜“式简单，点一两下，一键完成登录；

• 第三层面，与该 DID 身份所绑定的所有 Web2 账户如 Twitter（当然，你的 Twitter 也必须是主动地去隐私化，无真名无真人头像等，比如著名 NFT OG 6529，即使出席大会也从不露真容）、Web3 抽象账户如智能合约钱包，都可以在保护用户隐私的前提下，被聚合到一起。即使被“人肉”，用户在真实世界里具体是“谁”也无从得知，最终也只能追查到一个线上的虚拟身份、一串数字罢了。

Web2 时代的 App，每一个用户都熟练使用一键登录。使用体验方便，且不用再输入恼人的密码。

对用户来说，登录 App 的好处：

• 第一次注册时需要密码；

• 后续可以永远使用 QQ、WeChat、支付宝登录。

同时对用户的坏处是：

• 数据主权，不在自己手上。使用平台（QQ、WeChat、支付宝）提供的账户体系；

• 被动接受各类基于隐私信息的广告，用户自己没得选。

Web3 的账号，尽管可以帮忙把数据主权拿出来，但绕不过去的问题是：账户授权和使用，能像 Web2 的一键登录那么流畅吗？

Next.ID 社区提出了 AuthService 这样的思路，试图来解决这个工程问题。它的设计流程如下：

1. 用户使用 Next.ID 的 AuthService SDK，进行 dApp 的账户授权操作，数据来源子用户绑定到 ProofService 的数据；

2. 授权操作通过用户自行部署的 VPS（Virtual Private Server，虚拟私人服务器）来验签；

3. 成功通过后，用户指定可以具体的 scope 开放出用户账号的相关隐私信息。

其中关键的第一步，登录 dApp 时使用 Next.ID：

第三步，授权时开放哪个账号的数据：

最后第五/六步，开放账号的哪些数据出去：

以上是本期文章的所有内容，在后续的文章，我们将继续就「隐私」和「安全」的相关话题展开讨论，也将就 AuthService 背后的 VPS（Virtual Private Server，虚拟私人服务器）思路进一步进行说明。

感谢你的阅读，欢迎评论和转发。开源社区 Next.ID 也诚挚邀请你的加入，一起推进 DID 生态的落地。

官网：https://next.id/

开源代码：https://github.com/nextdotid

Discord: https://bit.ly/NextID_Discord_Official

添加社区经理微信：BinaryHB

社区双周会录制：

• 中文 B 站：https://space.bilibili.com/1004643496

• 英文 YouTube: https://www.youtube.com/channel/UC17C9xWKp0h_pZhfxbNtHsg

最近 DID（decentralized identity，去中心化身份）话题特别火，融资新闻也一个接一个。关于 DID 这个概念要如何理清却颇有争议，尽管处于这样的发展早期，很多理念并未完全明晰，不过对于一些已经出现的比较明显的困惑，我们有必要罗列出来，一起尝试看看，拨开 Web3 身份的技术迷雾。

1. 用户到底需要什么样的 DID，或者说什么样的 DID 体系;

2. Web2 的用户迁往 Web3 面临着什么样的迁移成本;

3. Web3 DID 能给用户带来什么在 Web2 中无法获得的东西。

据不完全披露，钱包领头羊 MetaMask 目前的月活用户数，起码是 3 千万以上的级别。这导致了大部分的 dApp，很自然的希望通过 MetaMask 来做身份层。而这个想法显然有非常多的挑战，毕竟 MetaMask 只是想做一个钱包而已。

先不论 MetaMask 有没有动机和动力，愿意维护这样海量级别的公共 API 来给 dApp 调用。一个始终绕不过去的，横亘在用户面前的大难题是：作为 EOA 类（externally owned address，外部所有者账户）钱包，只要我的私钥或者助记词丢失，我将丢失我对应账户里的所有资产。

只要 MetaMask 类的钱包无法解决这个巨大痛点，Web2 用户很难突然有勇气跳入 Web3 的兔子洞。

那 Web2 的用户目前是什么样的体验呢？

如果我们做一个简单比喻，把 Web2 里的姓名和身份证号（或者驾照、护照）这样的唯一 ID，分别对应于 Web3 的公钥地址和私钥。

可以发现，第一个问题：一个 Web2 用户即使丢失了身份证，即类比于私钥，Ta 依然可以通过中心化的认证机构之一国家公安机关，来重新申请一个身份证。Ta 的对应资产不会丢失。

以此类推，Web3 同样需要做到：私钥丢失后，我能不能通过去中心化的认证网络，通过什么样的方式来恢复对这个账户的控制呢？如果这个目标达成，在这一点上，Web2 用户迁移 Web3 的成本为零。

那么第二个问题：我有 MetaMask 钱包，我有币安等各类交易所的钱包，我还有各种 dApp 服务给我默认生成的钱包。这么多私钥，这么多助记词，我们是不是要等 Web3 重造一个去中心化版本的 1Password 或者 LastPass 来进行托管呢？用户成本大大增加，要去添加、管理所有的可能未来长到没有尽头的账户列表。简直要命。

所以问题出在哪里呢？让我们一起回到 Web2 世界想一想，就清楚了。

MetaMask 这样的钱包，本质上是一个银行户头，就好像我们在中国工商银行、花旗银行等等的账户，从而可以进行金融交易。我们只能使用身份证号（或者驾照、护照）这样的唯一 ID，去开一个新的银行开户。那如果我们持有中国工商银行的户头，去中国建设银行要求开户，可想而知一定会被工作人员请出去。

因为“身份”与“银行户头”，并不能直接画上等号。

并不止 Next.ID 社区持有这个观点，很多社区和 DID 产品也都这样认为，比如以太坊社区通过提案 EIP-2938，正式提出抽象账户（abstracted account），以此开发智能合约钱包。另一个很受欢迎的 DID 新产品 UniPass 也是采取类似思路。

也就是说，通过身份（公私钥对）与银行户头（抽象账户，钱包地址）的解耦，尝试建立一些全新的机制，我们得到前述难题的解法：

1. 私钥丢失不代表资产丢失，我可以用新的私钥去绑定已经丢失私钥的资产。

   1. 方式一，社交恢复（social recovery），通过过去已建立联系、链上留下高质量互动记录的好朋友们，给你进行担保的方式；

   2. 方式二，可以使用一系列等价于私钥级别的隐私安全问题，来辅助恢复账号。比如我小时候的宠物叫什么名字/我高中的英文老师是谁等等；

2. 所有相关抽象账户（Web2 IDs、Web3 抽象账户）的管理，可以直接绑定、收归到某一个数字身份（公私钥对）进行管理，在 Next.ID 里我们称之为数字化身 Avatar。神作电影《阿凡达》记得吧？半身不遂的人类 Jake 通过神经连接，控制着一个纳美星男性健全的身躯。是不是很像我们未来控制一个元宇宙里的数字化身？如示意图：

好的，到这里为止，我们算是把「定义 DID 身份的最底层是公私钥对」这一层说了个大概。当然了，作为 DID 的私钥管理问题，仍然有待整个 Web3 社区一起去探索，在未来通过社交恢复以及等同于密钥等级的个人隐私问答等等方案，一起来降低使用门槛。

前一阵，Tornado Cash 所带来的监管风暴，让很多 Web3 从业者感到后怕。直接查封地址，甚至还会连带封杀所有与之有过交易记录的地址，这种“满门抄斩株连九族”的做法令人不禁对 Web3 的抗审查性产生怀疑，信仰动摇。

与此同时，市面上很多 DID 项目做的就是粗暴的聚合服务，也不管是否链上链下账户，会不会有泄漏个人信息的风险，统统放到一起。那是不是等于说，在 zero knowledage proof（零知识证明）等隐私保护技术尚未完全成熟的今天，我们直接把自己拱手交出，好让监管部门一网打尽？

颇为尴尬。

有没有可能 DID 项目都太照顾项目方需求、反而忽视了用户的真正需求？

如果从用户角度出发，一个 DID 系统整体的落地方案，不仅包含前一小节我们谈到的「定义 DID 身份的最底层是公私钥对」，还至少包括往上的两个层面：

• 第二层面，在这套方案中，随意一个 DID 身份能够安全地满足，所有前来访问需要授权信息的 dApps 的并发调用流量，同时提供媲美 Web2 的 OpenID/OAuth 一样的丝滑体验，用户操作”傻瓜“式简单，点一两下，一键完成登录；

• 第三层面，与该 DID 身份所绑定的所有 Web2 账户如 Twitter（当然，你的 Twitter 也必须是主动地去隐私化，无真名无真人头像等，比如著名 NFT OG 6529，即使出席大会也从不露真容）、Web3 抽象账户如智能合约钱包，都可以在保护用户隐私的前提下，被聚合到一起。即使被“人肉”，用户在真实世界里具体是“谁”也无从得知，最终也只能追查到一个线上的虚拟身份、一串数字罢了。

Web2 时代的 App，每一个用户都熟练使用一键登录。使用体验方便，且不用再输入恼人的密码。

对用户来说，登录 App 的好处：

• 第一次注册时需要密码；

• 后续可以永远使用 QQ、WeChat、支付宝登录。

同时对用户的坏处是：

• 数据主权，不在自己手上。使用平台（QQ、WeChat、支付宝）提供的账户体系；

• 被动接受各类基于隐私信息的广告，用户自己没得选。

Web3 的账号，尽管可以帮忙把数据主权拿出来，但绕不过去的问题是：账户授权和使用，能像 Web2 的一键登录那么流畅吗？

Next.ID 社区提出了 AuthService 这样的思路，试图来解决这个工程问题。它的设计流程如下：

1. 用户使用 Next.ID 的 AuthService SDK，进行 dApp 的账户授权操作，数据来源子用户绑定到 ProofService 的数据；

2. 授权操作通过用户自行部署的 VPS（Virtual Private Server，虚拟私人服务器）来验签；

3. 成功通过后，用户指定可以具体的 scope 开放出用户账号的相关隐私信息。

其中关键的第一步，登录 dApp 时使用 Next.ID：

第三步，授权时开放哪个账号的数据：

最后第五/六步，开放账号的哪些数据出去：

以上是本期文章的所有内容，在后续的文章，我们将继续就「隐私」和「安全」的相关话题展开讨论，也将就 AuthService 背后的 VPS（Virtual Private Server，虚拟私人服务器）思路进一步进行说明。

感谢你的阅读，欢迎评论和转发。开源社区 Next.ID 也诚挚邀请你的加入，一起推进 DID 生态的落地。

官网：https://next.id/

开源代码：https://github.com/nextdotid

Discord: https://bit.ly/NextID_Discord_Official

添加社区经理微信：BinaryHB

社区双周会录制：

• 中文 B 站：https://space.bilibili.com/1004643496

• 英文 YouTube: https://www.youtube.com/channel/UC17C9xWKp0h_pZhfxbNtHsg