最近DID（decentralized identity，去中心化身份）話題特別火，融資新聞也一個接一個。關於DID 這個概念要如何理清卻頗有爭議，儘管處於這樣的發展早期，很多理念並未完全明晰，不過對於一些已經出現的比較明顯的困惑，我們有必要羅列出來，一起嘗試看看，撥開Web3 身份的技術迷霧。
本文邀請大家討論：
用戶到底需要什麼樣的DID，或者說什麼樣的DID 體系;
Web2 的用戶遷往Web3 面臨著什麼樣的遷移成本;
Web3 DID 能給用戶帶來什麼在Web2 中無法獲得的東西。
MetaMask 錢包是DID？
據不完全披露，錢包領頭羊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 也是採取類似思路。
也就是說，通過身份（公私鑰對）與銀行戶頭（抽象賬戶，錢包地址）的解耦，嘗試建立一些全新的機制，我們得到前述難題的解法：
私鑰丟失不代表資產丟失，我可以用新的私鑰去綁定已經丟失私鑰的資產。
方式一，社交恢復（social recovery），通過過去已建立聯繫、鏈上留下高質量互動記錄的好朋友們，給你進行擔保的方式；
方式二，可以使用一系列等價於私鑰級別的隱私安全問題，來輔助恢復賬號。比如我小時候的寵物叫什麼名字/我高中的英文老師是誰等等；
所有相關抽象賬戶（Web2 IDs、Web3 抽象賬戶）的管理，可以直接綁定、收歸到某一個數字身份（公私鑰對）進行管理，在Next.ID 裡我們稱之為數字化身Avatar。神作電影《阿凡達》記得吧？半身不遂的人類Jake 通過神經連接，控制著一個納美星男性健全的身軀。是不是很像我們未來控制一個元宇宙裡的數字化身？如示意圖：
好的，到這里為止，我們算是把「定義DID 身份的最底層是公私鑰對」這一層說了個大概。當然了，作為DID 的私鑰管理問題，仍然有待整個Web3 社區一起去探索，在未來通過社交恢復以及等同於密鑰等級的個人隱私問答等等方案，一起來降低使用門檻。
我們有沒有從第一性原理出發考慮DID？
前一陣，Tornado Cash 所帶來的監管風暴，讓很多Web3 從業者感到後怕。直接查封地址，甚至還會連帶封殺所有與之有過交易記錄的地址，這種“滿門抄斬株連九族”的做法令人不禁對Web3 的抗審查性產生懷疑，信仰動搖。
與此同時，市面上很多DID 項目做的就是粗暴的聚合服務，也不管是否鏈上鍊下賬戶，會不會有洩漏個人信息的風險，統統放到一起。那是不是等於說，在zero knowledage proof（零知識證明）等隱私保護技術尚未完全成熟的今天，我們直接把自己拱手交出，好讓監管部門一網打盡？
頗為尷尬。
有沒有可能DID 項目都太照顧項目方需求、反而忽視了用戶的真正需求？
如果從用戶角度出發，一個DID 系統整體的落地方案，不僅包含前一小節我們談到的「定義DID 身份的最底層是公私鑰對」，還至少包括往上的兩個層面：
一方面，在這套方案中，隨意一個DID 身份能夠安全地滿足，所有前來訪問需要授權信息的dApps 的並發調用流量，同時提供媲美Web2 的OpenID/OAuth 一樣的絲滑體驗，用戶操作”傻瓜“式簡單，點一兩下，一鍵完成登錄；
另一方面，與該DID 身份所綁定的所有Web2 賬戶如Twitter（當然，你的Twitter 也必須是主動地去隱私化，無真名無真人頭像等，比如著名NFT OG 6529，即使出席大會也從不露真容）、Web3 抽象賬戶如智能合約錢包，都可以在保護用戶隱私的前提下，被聚合到一起。即使被“人肉”，用戶在真實世界裡具體是“誰”也無從得知，最終也只能追查到一個線上的虛擬身份、一串數字罷了。
用戶需要的Web3 “一鍵登錄”會是什麼樣？
Web2 時代的App，每一個用戶都熟練使用一鍵登錄。使用體驗方便，且不用再輸入惱人的密碼。
對用戶來說，登錄App 的好處：
第一次註冊時需要密碼；
後續可以永遠使用QQ、WeChat、支付寶登錄。
同時對用戶的壞處是：
數據主權，不在自己手上。使用平台（QQ、WeChat、支付寶）提供的賬戶體系；
被動接受各類基於隱私信息的廣告，用戶自己沒得選。
Web3 的賬號，儘管可以幫忙把數據主權拿出來，但繞不過去的問題是：賬戶授權和使用，能像Web2 的一鍵登錄那麼流暢嗎？
Next.ID 社區提出了AuthService 這樣的思路，試圖來解決這個工程問題。它的設計流程如下：
用戶使用Next.ID 的AuthService SDK，進行dApp 的賬戶授權操作，數據來源子用戶綁定到ProofService 的數據；
授權操作通過用戶自行部署的VPS（Virtual Private Server，虛擬私人服務器）來驗簽；
成功通過後，用戶指定可以具體的scope 開放出用戶賬號的相關隱私信息。
其中關鍵的第一步，登錄dApp 時使用Next.ID：
第三步，授權時開放哪個賬號的數據：
最後第五/六步，開放賬號的哪些數據出去：
以上是本期文章的所有內容，在後續的文章，我們將繼續就「隱私」和「安全」的相關話題展開討論，也將就AuthService 背後的VPS（Virtual Private Server，虛擬私人服務器）思路進一步進行說明。
感謝你的閱讀，歡迎評論和轉發。開源社區Next.ID 也誠摯邀請你的加入，一起推進DID 生態的落地。
關於Next.ID
Next.ID 是世界上第一個為去中心化身份提供服務的協議（DIaaS），作為去中心化的身份聚合協議，整合了所有Web2 和Web3 的數字身份，為開源開發者和項目提供全面的、可驗證的身份數據庫，以便於創新和開發dApps。
作為世界上第一個為去中心化身份提供服務的協議（Decentralized-Identity-As-A-Service, DIaaS），Next.ID 創建了一個身份基礎設施，將用戶的身份安全地聚合到Avatars（即基於密碼學生成的用戶數字化身）。在Web3 生態中，Next.ID 會成為各類去中心化社交協議和dApp 的身份聚合關口。
