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，但是这做出来显然是冗余的。
可能是一个商业规划和生态建设问题，希望有人能回答。
1 Like
janx
February 10, 2019, 4:46pm
2
这是个很好的问题。
我赞同这个逻辑。Layer 1 for layer 2是一个长期目标。CKB在设计中为layer2考虑的各个要素，并不能在早期为CKB带来更多的优势，这些设计想要保证的是在CKB如愿成长起来之后，其发展不会遇到瓶颈。CKB必须先得到用户的认可，有了足够的需求，layer 2才有生存的空间。如何从0到1建立生态，增长用户，如楼主所说更多的是一个商业规划和生态建设问题，我并不是回答这个问题的最佳人选，我能说的是，这些都在思考和计划中
我对这个逻辑也有不同的看法。对于有长远目标的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。
5 Likes
Jan 你的两个点我都能同意，这是从两个角度对这个问题的思考：从生态建设角度和 CKB 的设计角度。
如果认可 CKB 会面对早期面对非 Layer 2 生态建设的问题，那么 CKB 有什么样的特性能够吸引用户/开发者的参与呢？经济模型的设计似乎并没有表现对开发者友好的一面，那么在开发者体验上是否有相关的设计？
janx
February 12, 2019, 2:42am
4
对于开发者友好的点：
RISC-V based VM - CKB-VM使用的是RISC-V指令集，而非任意自定义的指令集。RISC-V生态本身的强大不用我多说。这意味着CKB有更加成熟的开发环境，在智能合约语言的选择上开发者有更多的灵活性，相应的开发工具也更加健全。CKB目前提供的用ruby写脚本的demo（其中用户自定义了一个token）就是很好的例子。CKB-VM使得CKB可以拥抱更广范的开发者群体。Ref [1][2]
一个新的Dapp范式。CKB是一个Verification System，而不是一个Computation System（见我之前的talk以及对State Transaction的分析），这意味着在CKB上开发应用，业务逻辑自然的应该放在链外而不是链上，链上要做的只是必要的验证逻辑，这一点继承了Bitcoin的思路，与其他智能合约平台是不同的。观察现有的DApp我们也可以看到，链外业务逻辑+链上资产是一个普遍思路。CKB把这件事情变得更容易，因为它的编程模型天然匹配这个思路。（虽然其他的智能合约平台也可以实现这一点，但是这就和用C去做函数式编程一样，不是能不能的问题，而是合适不合适的问题。）
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团队找到了一个令人兴奋的方案，却发现没有一个平台支持这个方案依赖的密码学原语，是不是一件很遗憾的事情？
灵活的交易签名 - CKB的交易签名验证不是硬编码的secp256k1，而是用户可以自己选择的（这一点和Bitcoin比较像，Ethereum是硬编码的）。这意味着开发者可以自行选择更合适自己场景的签名方案（很多地方，例如流行的移动操作系统中，secp256k1是不支持的）。这也意味着CKB开发者可以实现更多的场景，例如multisig（可以思考一下Ethereum实现的Multisig和Bitcoin的Multisig有什么不同），Ring signature mixer，etc.
对开发者更加友好的token economics - CKB的Token Economics试图对齐所有参与者的激励：miner, holder, developer, user，也试图解决现有的DApp面临的一些痛点。例如：用户在使用DApp之前必须要持有ether，这是一个极高的门槛，而EOS那样的设计并不能解决本质问题，是否还有其它的可能性？这些依然在设计中，我们会在RFC中详细介绍，这里先卖个关子
最后总结一下：CKB是一个非常抽象的系统。抽象的意思是，凡是我们认为可以在上层实现的逻辑，全部放到上层实现，保持底层的最小化。这样做的好处有两个：1. 底层足够小足够简单，更容易保证安全；2. 上层开发者拥有更强大的编程模型，更多的选择，可以更好的应对自己的场景，不需要削足适履。 我们基于过去的底层和DApp开发经验做了这些考虑，未来也希望能从社区得到更多的反馈，帮助我们完善CKB的设计。
[1] https://github.com/nervosnetwork/ckb-demo-ruby-sdk https://github.com/nervosnetwork/ckb-ruby-scripts
5 Likes
我们对CKB初期的预计是，大部分应用会直接运行在CKB上而不是layer 2上，毕竟用户需求会是一个缓慢增长的过程，不会一下子触到性能瓶颈，我们也不希望用拔苗助长的方式来提高用户数量，无论是协议还是实现都需要时间打磨。