对DFINITY的去中心化身份、账户与钱包介绍 开发者能如何利用?_DEFI:DeFiDrop

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

6月3号,ICPLeague联合社区开发者举办了第二期的开发者电话会,探讨了DFINITY的底层账户结构,以及上层去中心化身份认证的方式,介绍了两者的联系方式。点击“阅读原文”可以查看视频回放。

本期亮点:

DFINITY的账户与身份是两个系统,其底层依然是加密原生的公钥/私钥/地址的账户,但在上层建立了去中心化身份系统;

身份与账户并不耦合,账户写在链的底层,而身份是链上运行在NNS子网上的智能合约,通过合约与账户建立了联系;

账户更像是银行卡,而身份更像是绑定了银行卡的支付宝,能方便地使用DFINITY的dapp;

身份系统的目的是为了帮助用户更好地管理账户,避免用户直接接触私钥;

在使用DFINITY的身份登陆其他DApps时,如果DApps相关代码更新,容易丢失对这个DApps的子账户信息;

开发者可以结合官方的命令行账户钱包实现客户端/网页钱包,或者基于互联网身份系统实现web3逻辑下的业务,比如个人存储、链上分身、数据集市。

账户地址

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

在选取的算法上,DFINITY的账户与比特币更相似,以PythonECDSA和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库中实现了一个命令行钱包

互联网身份

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

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

在使用II时,用户会获得名为“usernumber”的一串数字,这其实是II合约内部的一个索引。这串数字来自一个63位的字符串,一般五个一组用“-”隔开,被称为“PrincipalID”。

用户身份其实是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在账户系统外又开发了一套身份系统称之为“互联网身份”,以下简称“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字节的“PrincipalID”,和32字节的钱包账户“AccountID”。

PrincipalID的产出:

对blob添加4个字节小大的CRC-32的纠错码;

使用Base32对结果进行编码,每组五个字符,用“-”隔开;

也可以使用ASCII表示,最大63个字符。

AccountID的产出:

在blob前加入Account类型的特定字符串,后面加上序号;

对这个字符串计算sha224,得到28字节结果;

对结果添加4字节大小的CRC-32的纠错码,得到32字节结果;

转化为64个字符的字符串。

AccountID就是我们在交易所中使用的转账地址,而AccountID也可以衍生出多个子地址,之需要修改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的上层搭建更多应用,比如为每一个账户建立独立的存储空间,作为数据确权的中心,或者去优化多身份系统,从多身份中衍生出交互的多样性。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金智博客

[0:0ms0-7:82ms