对于开发者友好的点：
-
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
[2] https://github.com/nervosnetwork/ckb-ruby-scripts