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」与「.ic0.app」后可以在浏览器直接访问,如「https://h5aet-waaaa-aaaab-qaamq-cai.raw.ic0.app/」。这是其与以太坊账户体系一个很大的不同。

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

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

互联网身份(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 智能合约进行验证,完成登陆。

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

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

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

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

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

深入探讨 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 对现在的加密原生用户的使用习惯来是超前的,因此大家很难接受。消除这个断层,改进这个机制是非常重要的一个工作,比如为 keysmith 命令行钱包做可视化页面等。

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

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

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

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

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