链下结算,链上验证。链上合约难于实现复杂的功能,比如参数存储。
这一特点导致了 Nervos-CKB 上的 DApp 容易被人挑刺,不够去中心化。
为什么要在链上部署智能合约?
大部分的产品就是为了使用区块链的去中心化属性,使得所部署的应用是真正的DApp,无法被任何人控制,验证 与 结算,都发生在链上,只要开源的代码被阅读后没发现后门 bug,那么它的DApp属性是可靠的。至少会让知道的人心里,不会产生去中心化质疑。
如果在 CKB 上实现一个具备惩罚功能的 DApp,那么惩罚这部分功能是不能在合约实现的,因为惩罚的证据,依赖链下提供,而不能一开始就使用存储在链上的数据来综合分析。链下提供的数据,如果数据源都有问题,验证的过程公平有何意义?
要理解 CKB 的链上验证,可以理解这个例子:将参数 1 和 1 传输到链上的合约,判断是不是 1+1 = 2。正确返回 true,否则返回 false。
明显地,依赖这一验证特性,是可以实现一些更加复杂且有趣的功能的,比如验证某条其它链的签名是否正确。你使用 CKB 钱包,在 CKB 区块链上给一个 ETH 的钱包地址A转账,这笔转账存放在链上 cell 中,lock_script 明确了当有人提供某条签名信息,且被 CKB 某个功能合约以 ETH 的验签方式校验与地址A 相等,那么就证明签名信息提供者是有地址A对应的私钥的,他可以消费这个cell,即 output。
如此地,实现了弱意义上的 CKB 链上的跨链收款功能,注意此时所有事情依然是发送在 CKB 公链上,并没有说是在 ETH 链。
然而,这种跨链收款功能,在 ETH 上也是可以实现的。ETH 本身的智能合约功能已经很强大,在已支持的算法之内,实现一个链上验签的功能,是绰绰有余的。链下输入: {RawMsg}, {SignMsg},链上获取:{TargetAddress},执行验签,结束。
这样一对比,CKB 智能合约的优点貌似不在上面那点。目前我能想到的:
- 就是它的智能合约虚拟机CKB-VM 支持多语言编程了;
- 可以实现可更新合约合约部署后无法更新一直是区块链开发者的心头之痛。
上面两点确实是方便了开发者,但无法弥补产品多样性上的缺陷。