关于 Nervos CKB 是一个 for layer 2 的 Layer 1 的疑惑


#1

Nervos CKB 如果我没有理解错的话,是通过分层设计解决不可能三角,所以一直是提出 layer 1 for layer 2。

的确以太坊、比特币有很多问题,他们都并不是为 layer 2 设计的,而 Nervos 一系列设计能看到是 for layer 2的。

但是问题在于,以太坊和比特币的 Layer 2 是自然产生的,产生的原因在于比特币和以太坊性能和手续费实在是太高,因此会有开发者认为做一个 Layer 2 是有利可图的。

也就是说,是先对比特币/以太坊有强烈的需求 — 但是因为比特币/以太坊可扩展性差满足不了大家的需求 — 有人发现了这个痛点 — 于是想要做 layer 2 来解决。

如果同意上面这个逻辑链条的话,我们就清楚:前提是有强烈的需求。

那么 Nervos 作为一条新的公链,安全等先不说,PoW 性能是不会很高的,但是在早期很难短时间内对 Nervos 的 token (发现还不知道叫什么,难道是 NOS?)有强烈的需求,那么这个 for layer 2 的 layer 1 该怎么做?

可以自己做 layer 2 ,比如秘猿的 CITA,但是这做出来显然是冗余的。

可能是一个商业规划和生态建设问题,希望有人能回答。


#2

这是个很好的问题。

  1. 我赞同这个逻辑。Layer 1 for layer 2是一个长期目标。CKB在设计中为layer2考虑的各个要素,并不能在早期为CKB带来更多的优势,这些设计想要保证的是在CKB如愿成长起来之后,其发展不会遇到瓶颈。CKB必须先得到用户的认可,有了足够的需求,layer 2才有生存的空间。如何从0到1建立生态,增长用户,如楼主所说更多的是一个商业规划和生态建设问题,我并不是回答这个问题的最佳人选,我能说的是,这些都在思考和计划中 :slight_smile: 我们对CKB初期的预计是,大部分应用会直接运行在CKB上而不是layer 2上,毕竟用户需求会是一个缓慢增长的过程,不会一下子触到性能瓶颈,我们也不希望用拔苗助长的方式来提高用户数量,无论是协议还是实现都需要时间打磨。

  2. 我对这个逻辑也有不同的看法。对于有长远目标的layer 2团队来说,一开始就加入Nervos社区,参与到CKB和其他协议的设计中来,同样是一个非常好的选择。今天的layer 2方案,无论是闪电网络还是plasma等等,都远谈不上成熟。Nervos的优势在于,我们是从整体在考虑layer 1和layer 2的设计与交互,而不是绑住一条腿去改造另外一条腿。如果在有限的设计空间中腾挪并不能给你的layer 2方案带来多大的优势,为什么不考虑另外一个有更大施展空间更有潜力的layer 1呢?Nervos是唯一一个在项目初期就建立对社区友好的RFC流程,和社区共同推进协议设计的区块链项目。

顺便说一句:layer 1 for layer 2只是CKB的目标之一而不是全部,请关注近期要发布的经济模型RFC。


#3

Jan 你的两个点我都能同意,这是从两个角度对这个问题的思考:从生态建设角度和 CKB 的设计角度。

如果认可 CKB 会面对早期面对非 Layer 2 生态建设的问题,那么 CKB 有什么样的特性能够吸引用户/开发者的参与呢?经济模型的设计似乎并没有表现对开发者友好的一面,那么在开发者体验上是否有相关的设计?


#4

对于开发者友好的点:

  1. RISC-V based VM - CKB-VM使用的是RISC-V指令集,而非任意自定义的指令集。RISC-V生态本身的强大不用我多说。这意味着CKB有更加成熟的开发环境,在智能合约语言的选择上开发者有更多的灵活性,相应的开发工具也更加健全。CKB目前提供的用ruby写脚本的demo(其中用户自定义了一个token)就是很好的例子。CKB-VM使得CKB可以拥抱更广范的开发者群体。Ref [1][2]

  2. 一个新的Dapp范式。CKB是一个Verification System,而不是一个Computation System(见我之前的talk以及对State Transaction的分析),这意味着在CKB上开发应用,业务逻辑自然的应该放在链外而不是链上,链上要做的只是必要的验证逻辑,这一点继承了Bitcoin的思路,与其他智能合约平台是不同的。观察现有的DApp我们也可以看到,链外业务逻辑+链上资产是一个普遍思路。CKB把这件事情变得更容易,因为它的编程模型天然匹配这个思路。(虽然其他的智能合约平台也可以实现这一点,但是这就和用C去做函数式编程一样,不是能不能的问题,而是合适不合适的问题。)

  3. Crypto primitive. CKB-VM的指令集里面没有任何特殊的密码学指令,这一点与所有的区块链都不一样:在Bitcoin Script里面有OP_CHECK系列指令用于验证签名,在Ethereum里面有ecrecover以及后来通过硬分叉增加的pairing check precompiles,这些都是在底层硬编码实现的密码学原语。CKB在底层没有硬编码任何密码学相关的原语,甚至最简单的交易验证用的secp256k1都是一个跑在CKB-VM里面的合约,cell通过引用这个合约来实现lock script。我想强调一下:这是一个非常疯狂的想法! 以前之所以没有人这么做,是因为在上层实现的密码学原语效率很低,要实现这个目标对虚拟机优化的要求非常高。我们做这个选择是基于我们做的大量调研和实验,以及我们对RISC-V生态的信心。而这个选择的优点也是非常明显的:在CKB上增加密码学原语不需要硬分叉!增加密码学原语甚至都不需要社区讨论,DApp或是Layer2开发者自己就可以部署自己需要的密码学原语,所要做的仅仅是找到这个密码学原语的C实现(或是任何一种gcc/llvm工具链可编译的实现)然后部署到CKB-VM上。 这一点其他任何区块链都是做不到的,想想看,一个layer2团队找到了一个令人兴奋的方案,却发现没有一个平台支持这个方案依赖的密码学原语,是不是一件很遗憾的事情?

  4. 灵活的交易签名 - CKB的交易签名验证不是硬编码的secp256k1,而是用户可以自己选择的(这一点和Bitcoin比较像,Ethereum是硬编码的)。这意味着开发者可以自行选择更合适自己场景的签名方案(很多地方,例如流行的移动操作系统中,secp256k1是不支持的)。这也意味着CKB开发者可以实现更多的场景,例如multisig(可以思考一下Ethereum实现的Multisig和Bitcoin的Multisig有什么不同),Ring signature mixer,etc.

  5. 对开发者更加友好的token economics - CKB的Token Economics试图对齐所有参与者的激励:miner, holder, developer, user,也试图解决现有的DApp面临的一些痛点。例如:用户在使用DApp之前必须要持有ether,这是一个极高的门槛,而EOS那样的设计并不能解决本质问题,是否还有其它的可能性?这些依然在设计中,我们会在RFC中详细介绍,这里先卖个关子 :smiley:

最后总结一下:CKB是一个非常抽象的系统。抽象的意思是,凡是我们认为可以在上层实现的逻辑,全部放到上层实现,保持底层的最小化。这样做的好处有两个:1. 底层足够小足够简单,更容易保证安全;2. 上层开发者拥有更强大的编程模型,更多的选择,可以更好的应对自己的场景,不需要削足适履。 我们基于过去的底层和DApp开发经验做了这些考虑,未来也希望能从社区得到更多的反馈,帮助我们完善CKB的设计。

[1] https://github.com/nervosnetwork/ckb-demo-ruby-sdk
[2] https://github.com/nervosnetwork/ckb-ruby-scripts


Nervos 双周报#3:佛系新年之后的开工大吉!