这些都是开发者试图提升用户体验所想出来的好办法，但对于每一条新的公链，密钥对管理的本质都是需要有一组新地址和密钥，这个问题是一直存在的。

上述的公私钥验证方式不够灵活的问题，在比特币、以太坊等较为先发的公链上或许还不明显，因为他们已经有既有的用户，这些用户也被折磨习惯了。但对于近期兴起的公链而言，如果还存在和先前公链同样的进入摩擦成本，那么就是给用户设置了障碍，也会影响开发者是否想要在这个公链上开发的意愿。

一个对用户有学习成本的公链，在获取用户上就存在着先天的壁垒，即使这些公链有其他的亮点，可能对于开发者而言，也不会那么有吸引力，因为他们知道很多的用户可能都被这些不友善的用户体验给吓走了。

另外，密码学原语不能够灵活使用的问题，影响的层面还不止于公私钥的保存。对于开发者而言，如果以后他们想用更先进的密码学原语来保证隐私及安全，一样会面临到底层的虚拟机能不能部署，以及支持签名验证的挑战。当然还会影响目前大家讨论的很热的话题：跨链，因为不同的链使用的密码学原语也会有所不同，在虚拟机验证交易时就会遇到这个难题，这也是为什么目前许多同构跨链的解决方案（Cosmos / Polkadot ）可行，但对于异构跨链的方案却停滞不前的原因。

Nervos 的设计有何不同？

在 Nervos CKB 中，除了交易排序外，没有其他硬编码的密码学原语，资产所有权的验证是通过 cell 中的 lock script 来做验证，其中的验证规则和使用的密码学原语都是可以自定义的，因此几乎所有的密码学原语都可以被开发者灵活的使用。

套用一句 Nervos 研究员 Cipher 老师的话来说，就是：「在 CKB 上除了最基础的交易排序以外，其余都是应用层的内容。」这让开发者拥有了非常大的开发弹性，去进行各式各样的开发，例如更自由的账户验证方法等。

因为在基于 RISC-V 的 CKB-VM 中，要求的就是一套能够符合 RISC-V 编码的验证规则而已，开发者有很多能够自由挥洒的空间。下图可以看出 Nervos 和其他可以支持智能合约的公链在灵活度上的差异，应用层的内容表示的是可以去做自定义的，协议层代表的是需要经过「分叉」才能改动的内容。

以目前 Nervos 的 Grnats 团队 Lay2 为例，为什么他们开发的 pw-sdk 能够用以太坊的地址，甚至是 ENS 来接收 CKB？是因为在 CKB 上，地址是开发者可以任意把玩的应用层内容。理论上只要链上有已经有验证规则的 cell 和非对称加密的加密算法库，这种地址生成规则就能够被验证。例如我们可以把以太坊的 Keccak-256 （SHA-3）的签名算法和验证规则和比特币的 SHA-256 都部署在链上，那么未来的其他开发者就可以用 cell deps 进行调用。 (责任编辑：admin)