原始 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 登陆，比如通过邮箱去做密码学验证。 (责任编辑：admin)