深入解读 DFINITY 账户结构与去中心化身份机制

原文标题：《对 DFINITY 的去中心化身份、账户与钱包介绍，开发者能如何利用？》

作者：blockpunk

6 月 3 号，ICP League 联合社区开发者举办了第二期的开发者电话会，探讨了 DFINITY 的底层账户结构，以及上层去中心化身份认证的方式，介绍了两者的联系方式。

本期亮点：

• DFINITY 的账户与身份是两个系统，其底层依然是加密原生的公钥 / 私钥 / 地址的账户，但在上层建立了去中心化身份系统；
• 身份与账户并不耦合，账户写在链的底层，而身份是链上运行在 NNS 子网上的智能合约，通过合约与账户建立了联系；
• 账户更像是银行卡，而身份更像是绑定了银行卡的支付宝，能方便地使用 DFINITY 的 dapp；
• 身份系统的目的是为了帮助用户更好地管理账户，避免用户直接接触私钥；
• 在使用 DFINITY 的身份登陆其他 DApps 时，如果 DApps 相关代码更新，容易丢失对这个 DApps 的子账户信息；
• 开发者可以结合官方的命令行账户钱包实现客户端 / 网页钱包，或者基于互联网身份系统实现 web 3 逻辑下的业务，比如个人存储、链上分身、数据集市。

账户地址

一般用户在互联网身份的包装下并没有接触到转账地址，但 DFINITY 作为区块链系统具备与比特币/以太坊类似的账户，账户验证的主要机制是经典的数字签名方案。即从种子派生公私钥对，并将公钥匙处理编码为字符串地址，通过私钥签名发送交易，使用公钥验证鉴别交易。

在选取的算法上，DFINITY 的账户与比特币更相似， 以 Python ECDSA 和 secp256k1 为主，如果使用已有的比特币账户在 DFINITY 上能生成一样的公钥，但在地址表现形式上有所不同。

DFINITY 的账户地址的长度为 64 个字符，这种格式只用于表示普通账户，DFINITY 容器（合约）使用专门的 23 位的容器 ID 表示，并 5 个字符串一组，用「-」隔开，如「h5aet-waaaa-aaaab-qaamq-cai.raw」，加上「https」与「.ICO.app」后可以在浏览器直接访问，如「https://h5aet-waaaa-aaaab-qaamq-cai.raw.ICO.app/」。这是其与以太坊账户体系一个很大的不同。

在 nns.ICO.app 下的 Accounts 下能看到这些账户地址，可以直接用于 ICP 的转账，但目前还没有易用的加密原生钱包。

但官方其实开源了这类钱包的实现方法，在keyith 库中实现了一个命令行钱包。

互联网身份（II）

DFINITY 在账户系统外又开发了一套身份系统称之为「互联网身份（Internet Identity）」，以下简称 II。II 是部署在 DFINITY 的一个智能合约，智能合约的状态存储中对地址与身份建立了映射。

注意的是，身份和钱包账户是两回事。以太坊上钱包地址就是你使用应用的身份，但是在 DFINITY 中，身份是与钱包账户分开，两者不耦合的，但来自同一源头的公私钥对，而且可以互相演化的。

在使用 II 时，用户会获得名为「user number」的一串数字，这其实是 II 合约内部的一个索引。这串数字来自一个 63 位的字符串，一般五个一组用「-」隔开，被称为「Principal ID」。

用户身份其实是 II 智能合约中的一个实例化对象，II 是 DFINITY 推动的标准，目前 DFINITY 上的应用都可以通过引入几行代码，来允许用户使用 II 标准登陆应用。II 是一种中心化身份的标注，使用了具备高度安全性的双要素验证；并能在使用不同 dapp 时为用户创建衍生身份，来保护用户隐私防止被跨应用追踪账户；并能更方便的管理多账户，无需账户密码，也无需基础学习门槛高的私钥，通过面部识别、指纹扫描或 YubiKey 等安全终端轻松地使用。

首先介绍一下 WebAuthn，符合了 W3C （万维网联盟）的 Web 验证的标准，也就是除去账户密码 / 私钥验证之外，还需要安全硬件的验证，这是为了避免钓鱼网站与恶意软件的侵害。因此在使用 II 时，用户必须具备安全硬件，这也是困扰早期用户的一个门槛，但目前我们的大部分手机、笔记本都装载了安全芯片，也可以外接 YubiKey。

WebAuthn 验证流程：

• 用户启动登录过程后，DFINITY 的 II 智能合约将生成一个随机质询并将其发送到用户的浏览器；
• 然后浏览器将质询转发到安全设备，用户在安全设备上进行交互验证，如指纹解锁、面部识别或轻触 YubiKey；
• 完成验证，使用保存在安全设备中的私钥签名；
• 然后将验证后签名的质询发送回 II 智能合约，II 智能合约进行验证，完成登陆。

在我们使用 II 授权登陆一个 DApp 时，II 会自动产生一个子身份专门用于使用该 DApp。这为用户创建了多个链上分身，防止其身份被追踪；同时 DFINITY 对不同容器交互时都需要分别进行验证，一个容器无法盗用其授权权限与其他容器交互，来转走代币，而这种事曾在以太坊上发生过。

同时，II 合约也对身份进行了一个抽象，因此即使你的私钥只存储在设备的安全芯片中，并不传输，但你能把多个设备绑定在一个主账户下，使用多个设备直接登陆主账户发送任意操作。这是一种对权限的管理，具体需要官方公布更多细节。

互联网身份与账户地址的联系

DFINITY 在账户系统外又开发了一套身份系统称之为「互联网身份（Internet Identity）」，以下简称「II」。II 是部署在 DFINITY 的一个智能合约。

原始 ID 的产出：

• 首先对随机数 Rand 进行 Bip39，然后产出种子文件，再推断出私钥；
• 通过私钥产出一个 DER 格式的公钥，长度为 65 字节；
• 对公钥进行 sha224 得到 28 字节的字符串，然后加上一个字节判断其类，产出 29 字节的原始 ID 以下称「blob」；

这里添加了一个字节可以表示其的类，「0x01」为系统保留，「0x02」代表了这是主要 ID，即用户创建的；「0x03」表示该共钥是从主要 ID 派生的，一个主要 ID 具备一个空间，可以注册很多个派生 ID，去使用不同的 DApp；「0x04」为匿名 ID，不用签名也可以发送请求。

此时，对 blob 的两种处理方式分别产出了用于 II 合约的 63 字节的「Principal ID」，和 32 字节的钱包账户「Account ID」。

Principal ID 的产出：

• 对 blob 添加 4 个字节小大的 CRC-32 的纠错码（error detection code）；
• 使用 Base32 对结果进行编码，每组五个字符，用「-」隔开；
• 也可以使用 ASCII 表示，** 63 个字符。

Account ID 的产出：

• 在 blob 前加入 Account 类的特定字符串，后面加上序号；
• 对这个字符串计算 sha224，得到 28 字节结果；
• 对结果添加 4 字节大小的 CRC-32 的纠错码，得到 32 字节结果；
• 转化为 64 个字符的字符串。

Account ID 就是我们在交易所中使用的转账地址，而 Account ID 也可以衍生出多个子地址，之需要修改 blob 后的序号即可，被哈希后就能得出不同的地址，这个过程与之前的派生是有区别的。

注意问题

目前 DFINITY 官方鼓励开发者使用 II 去登陆 DApp，而 II 对身份与地址的衍生与存储都运行在智能合约中。

而在 DFINITY 的合约中 Persistent 状态是允许被更新的，因此合约可以被升级，但这并不是一个持久化的状态，因此有可能会在更新中损失数据。这就意味着，在 II 合约自身，或者 DApp 合约更新后，可能会损失数据，导致过去使用 DApp 的身份丢失。

这是所有开发者在使用 II 时需要注意的风险，但是这种情况往往是在使用 DApp 时会遇到的，而你持有的 ICP 代币不会受到影响。

注意问题

目前 DFINITY 的体验与加密原生用户中间有一个断层，II 对现在的加密原生用户的使用习惯来是超前的，因此大家很难接受。消除这个断层，改进这个机制是非常重要的一个工作，比如为 keyith 命令行钱包做可视化页面等。

还可以在登陆机制上进行探索，目前的 WebAuthn 登陆有一定硬件门槛，不是所有人都能很轻松的使用。比如使用metamask登陆，比如通过邮箱去做密码学验证。

在开发 DFINITY 钱包时可以更好的去结合加密原生的账户地址与 DFINITY 的多身份系统。做一个比喻，账户地址像是银行卡账户，DFINITY 的 II 是微信的账户，也可以使用这个微信账户去登陆不同的应用，每个应用你都具备一个身份。

因此将 MetaMask 还不足够，DFINITY 的体验与 Web3 中描述的「用钱包去完成所有的登录的操作」不同了，应用的连接感更像传统互联网的「一键登录」。

同时，在不同的公链或平台上都有去中心化身份的项目，而因为没有深度耦合， DFINITY 官方推出的 II 也可以早期的身份项目，开发者可以着手去改进它，或者实现一个全新的更好的身份系统。

同时也可以在 II 的上层搭建更多应用，比如为每一个账户建立独立的存储空间，作为数据确权的中心，或者去优化多身份系统，从多身份中衍生出交互的多样性。