去中心化身份：DID、可验证凭证与 ENS

互联网的身份体系建立在「中心化账本」上：平台掌握你的账号、数据与授权，你只是租户。去中心化身份（DID） 把这个账本搬到链上——身份由私钥控制、凭证由签发者签名、验证不再依赖单一平台。ENS 则让这串地址变成人类可读的名字，补齐了「可读身份层」。

本文按「DID 标准 → 注册表/解析器 → 可验证凭证生命周期 → VP 验证 → ENS 身份 → 与 OAuth 对比 → 落地选型」的顺序，把去中心化身份的每一层机制讲清楚。

前置：/blockchain-fundamentals/（区块链基础与密钥体系）、/wallet-integration-dapp/（钱包与链上账户）、/nft-standards-practice/（ERC-721，ENS 域名即 NFT）。

目录

• 1. 身份问题的本质：从中心化到去中心化
• 2. DID 标准：W3C DID Core 与 DID 方法
• 3. 去中心化注册表与解析器
• 4. 可验证凭证：VC 的生命周期
• 5. 展示与验证：VP 与最小披露
• 6. ENS：可读的链上身份层
• 7. ENS 与 Web3 身份整合
• 8. 与 Web2 OAuth 对比
• 9. 落地场景与实施选型
• 10. 速查表与一句话记忆
• 延伸阅读

1. 身份问题的本质：从中心化到去中心化

Web2 的身份模型：平台各自维护账号，身份与数据耦合在平台内，注册平台 A/B/C 导致身份碎片化，OAuth 只是委托「我们的人」给第三方，平台封号/倒闭则身份与数据一并丢失。

三大痛点：

SSI（自主权身份）四原则：存在（标识符由私钥派生）、控制（私钥即控制权）、可验证（签发者签名）、可移植（跨服务复用）。

记忆：身份三要素——标识符、凭证、授权——从「平台托管」变为「用户自持」，就是去中心化身份的核心迁移。

2. DID 标准：W3C DID Core 与 DID 方法

DID（Decentralized Identifier） 是 W3C 标准化的 URL：did:method:method-specific-id，如 did:ethr:0xb9c571...（以太坊）、did:key:z6Mkha...（公钥派生）、did:web:example.com（DNS+HTTPS）。method 决定解析逻辑，method-specific-id 方法内唯一、通常关联链上注册数据。

DID 文档（解析返回）描述验证方法与服务端点：

{
  "id": "did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a",
  "verificationMethod": [{
    "id": "#controller",
    "type": "EcdsaSecp256k1VerificationKey2019",
    "controller": "did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a"
  }],
  "authentication": ["#controller"],
  "service": [{ "id": "#didcomm", "type": "DIDCommMessaging",
                "serviceEndpoint": "https://agent.example.com/didcomm" }]
}

DID 方法的责任：定义如何生成/注册/解析/更新，含密钥轮换、停用与恢复规则。

决策：选 DID 方法看三点——解析是否去信任（ethr 靠链上事件）、密钥轮换是否原生支持、生态工具是否成熟；原型用 did:key，生产用 did:ethr 或 did:web。

3. 去中心化注册表与解析器

注册表（Registry）：DID 文档可链上存或「链外存 + 链上锚点」。以太坊的 did:ethr 把公钥更新写成链上事件：

contract DIDRegistry {
    event DIDAttributeChanged(bytes32 indexed did, bytes32 indexed name,
                              bytes value, uint validTo, uint previousChange);
    function setAttribute(bytes32 did, bytes32 name, bytes memory value, uint validTo)
        external { /* 更新后 emit 事件，供解析器索引 */ }
}

解析流程：DID → 识别 method → 对应解析器 → 读取注册数据 → 组装 DID 文档。通用解析器聚合多方法，链上解析器直接查 registry 事件，缓存层用 ENS+IPFS 降低解析延迟。

记忆：注册表负责「写入」、解析器负责「读取」——解析是身份的读路径，链上事件是它的可信数据源。

4. 可验证凭证：VC 的生命周期

VC（Verifiable Credential） 是签发者对「关于某个 DID 的声明」的加密签名，三角色模型：Issuer（签发）→ Holder（持有）→ 出示 → Verifier（验证）。

生命周期：发行（签发者签名）→ 存储（钱包加密）→ 出示（生成 VP）→ 验证（验签发者公钥 + 查吊销）→ 吊销（revocation registry）。

VC 的 JSON 结构（JWT 编码版）：

{
  "vc": {
    "@context": ["https://www.w3.org/2018/credentials/v1"],
    "type": ["VerifiableCredential", "EmploymentCredential"],
    "issuer": "did:web:company.example.com",
    "issuanceDate": "2026-08-01T00:00:00Z",
    "credentialSubject": {
      "id": "did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a",
      "position": "Senior Engineer", "employedSince": "2024-03-15"
    },
    "credentialStatus": { "type": "RevocationList2021Status",
                          "id": "did:web:company.example.com#revocation-list" }
  }
}

吊销机制：吊销列表（RevocationList）/ 状态位图（StatusList，高吞吐）/ 链上可校验（高可信）。

记忆：VC 的价值全在签名——签发者离线签好、持有者离线存好、验证者靠「签发者公钥 + 吊销状态」离线验证，全程不需要签发者在线。

5. 展示与验证：VP 与最小披露

VP（Verifiable Presentation） 是持有者「出示」的载体：把 VC 用持有者私钥签名打包，证明「我确实持有这些凭证」。验证方校验四步：VP 签名属于持有者 → 每张 VC 签名属于签发者 → 凭证未过期未吊销 → 签发者/持有者 DID 密钥当前有效（解析 DID 文档）。

最小披露（Selective Disclosure）：VC 拆成字段级证明，配合零知识只暴露必要子集——例如酒吧验证「已成年」时出示 age>=18 证明，不露生日/地址。工具：AnonCreds、BBS+ 签名、zk-SNARK 电路。

反重放：验证者通过 audience 字段（自己的 DID/域名）要求出示者签名，防止同一 VP 被别处重放。

决策：生产系统优先支持「可选择性披露」——默认全量出示、按风险降级到字段级证明；纯 ZK 电路只在强隐私场景上马，因为电路审计成本高。

6. ENS：可读的链上身份层

ENS（Ethereum Name Service） 把 0xb9C5...e8a 映射成 alice.eth，本质是 ERC-721 NFT + 链上解析器：Registry 合约记录所有者（可转移 NFT），Resolver 合约解析 name → 地址/文本/头像，并支持 sub.alice.eth 子域名分发。

常见记录类型：

用 ethers 解析 ENS：

const provider = new ethers.JsonRpcProvider("https://eth-mainnet.g.alchemy.com/v2/KEY");
const addr = await provider.resolveName("alice.eth");     // 域名→地址
const name = await provider.lookupAddress("0xb9c571..."); // 地址→域名
const email = await provider.getResolver("alice.eth").then(r => r?.getText("email"));

记忆：ENS 是「身份的可读层」——DID 是机器可解析的标识符，ENS 是给人看的名字，二者互补。

7. ENS 与 Web3 身份整合

整合栈：钱包（私钥）→ 地址 → alice.eth（可读）→ 关联 DID/VC/社交记录；DApp 用 SIWE 登录拿到地址，反查 ENS 组装链上档案。

签名登录（SIWE）流程：构造 EIP-4361 消息（nonce + 域名）→ 用户钱包签名 → DApp 验签并以 address 为会话标识 → 反查 ENS 名字与记录组装链上身份档案。

SIWE 消息示例：

app.example.com wants you to sign in with your Ethereum account:
0xb9c5714089478a327f09197987f16f9e5d936e8a
URI: https://app.example.com | Version: 1 | Chain ID: 1
Nonce: a1b2c3d4 | Issued At: 2026-09-30T09:00:00Z

身份聚合：ENS 把多链地址、社交账号、VC 公钥通过文本记录/子域名串起来，形成单一链上档案。

记忆：Web3 身份栈的落点不是「替代所有登录」，而是「先让链上身份可读可用」——ENS 解决可读、SIWE 解决登录、DID/VC 解决凭证。

8. 与 Web2 OAuth 对比

OAuth 仍有优势：SDK 生态成熟、密码找回、无钱包门槛、风控基础设施完备，且平台可执行 KYC/冻结等监管动作。

决策：存量 Web2 产品用「OAuth + 渐进式链上身份」；面向加密原生的产品才全量上 DID/VC——混合模式比一步到位更务实。

9. 落地场景与实施选型

四类场景：

实施决策清单：DID 方法（proto 用 did:key，生产 did:ethr/did:web）→ 凭证格式（JWT-VC vs JSON-LD VC）→ 存储（本地钱包 vs 托管凭证库）→ 吊销（StatusList vs 链上 registry）→ 验证端（自建 vs SSI 中间件 Trinsic/Spruce）→ 密钥恢复（必须设计轮换与恢复，否则丢失即永久失效）。

决策：先跑通「签发-存储-出示-验证」最小闭环，再补吊销与恢复；DID 方法与凭证格式是迁移成本最高的决策点，一开局就按生产规模选。

10. 速查表与一句话记忆

一句话记忆：去中心化身份 = DID（机器标识） + VC/VP（可验证凭证） + ENS（人类可读名字）——私钥是控制权、签名是可验证性、链上事件是可审计性，落地时先用 ENS+SIWE 打开登录，再按场景补 DID/VC 凭证层。

延伸阅读

• /blockchain-fundamentals/ — 区块链基础与密钥体系
• /wallet-integration-dapp/ — 钱包与 DApp 账户体系
• /nft-standards-practice/ — ENS 域名与 NFT 标准
• /blockchain-zkp-privacy/ — 零知识证明与最小披露
• /blockchain-nft-marketplace/ — 数字资产与身份市场
• [[blockchain-web3]] — 区块链 Web3 专题