在 CKB 上编程到底有什么样的优势?
2020/4/16 9:55:24
本文主要是介绍在 CKB 上编程到底有什么样的优势?,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
Nervos 从项目诞生之初,就一直秉持着自己的设计理念,坚持分层的设计方案,底层去解决安全和去中心化的问题,上层去解决效率、扩容、多功能的问题,希望可以通过这样的方式去解决区块链世界的不可能三角问题。Nervos 是一套完整的解决方案,经济模型、共识、虚拟机、Cell 模型、Layer 2 等等,相互之间环环相扣,形成一个完整又紧密的系统。
回到一个开发者所关心的问题,现在已经诞生这么多公链平台,那么在 Nervos CKB 上进行编程,究竟会有什么与众不同的体验?在 CKB 上编程,又有什么样的优势呢?
本文试着从 CKB 中资产是一等公民、编程上的灵活性,以及状态的确定性这三个角度进行阐述。
开发者发行的资产在 CKB 上都是一等公民
在 Nervos CKB 的设计哲学中,如果要将智能合约的风险降到最低,那么必须要将这些智能合约的「状态」去中心化。因为状态决定了资产的所有权,唯有将其去中心化,才能避免因状态的中心化而导致的智能合约漏洞,进而产生系统性风险,最终造成全部人的资产损失。
回顾过去,我们可以看到ERC20 的 Token 存在着许多系统的脆弱性,例如著名的 The DAO 事件,以及 2018 年美链的合约漏洞,它们都因为智能合约中有 bug,进而造成无数资产所有者的损失。
为什么单个合约漏洞就能造成如此大的伤害呢?因为 ERC20 发行的 Token 本质上是将所有用户的资产都存在一个合约地址中,因此当这些 dApp 产生漏洞时,所有该资产的状态都可能发生变动,从而造成经济损失。在 ERC20 这样的模型下发行的资产,就像将该种资产全部都锁进大金库中。可想而知,只要金库的任何一个地方发生了漏洞,那么外来的人就可以进入金库,并将所有的资产都搬走。
发行资产是区块链开发者的一项重要的需求,原生代币和其它发行的资产,都应该是一等公民(First-class Asset),也就是任何一个资产的所有者可以拥有自己的状态所有权,而不是像 ERC20 Token 那样,所有持有者的同类型资产都必须共用一把钥匙。因此,在 Nervos CKB 中,不论是持有 CKByte 这样的原生代币,还是持有其他用户自定义的 Token(User Defined Token,UDT),用户都是将这些资产分别锁在自己独自所有的小格子之中,并且只有用户自己才有解锁的钥匙。
为什么能够让资产成为一等公民?这是因为在 Nervos CKB 中,所有的资产都储存在泛化的 UTXO 模型——Cell 之中,并且可以通过 Cell 中的 lock script 验证所有权,以及通过 type script 验证新 cell 的生成,这样的状态储存与验证规则同时适用于 CKByte 和 UDT,因此降低了任何资产发行时,因合约漏洞而造成资产损失的风险。
CKB 是开发者能够任意玩耍的灵活平台
Nervos CKB?哦,这是条公链啊?那他们的智能合约用啥语言写啊?
这样的问题在 CKB 上是不存在的,因为 CKB VM 是基于开源的 RISC-V 指令集开发的,使用了广泛实现的 ELF 格式,也就是说,任何可以编译成 RISC-V 程序的语言均可以直接用来为 CKB 开发智能合约;同时结合 Cell 模型这样的编程模型,我们可以将待验证的合约放在 type script 中,并将所有权的验证放在 lock script 中,这两大设计可以让在 CKB 上的编程拥有非常大的灵活性。
我们简单列举了一些优势来告诉你 Nervos CKB 究竟灵活在哪里:
1.任何语言都有可能在 CKB 上开发:
CKB 核心只定义了底层的虚拟机模型,理论上任何提供了 RISC-V 后端的语言均可以用来开发 CKB 合约,而不需要局限在特定语言才能够进行编程,因此这样的设计在未来可以降低更多开发者的进入门槛,并且更能够捕获使用各种语言的开发者进入 CKB 生态之中。
2.你可以用各种密码学原语来作为资产的钥匙:
在 CKB 虚拟机上没有写死的密码学原语,因此任何密码学原语理论上都可以像普通的脚本一样被部署在 cell 中。这让 Nervos 的生态可以在不需要分叉的情况下,有了使用各种密码学技术的可能性。
这种特性的威力是巨大的,举例来说,你可以用以太坊和其他公链的地址和私钥去签署和收发 CKB 上的交易,因此如 MetaMask 等,这类在其他链上拥有成千上万用户的工具,可以在开发者开发好一款 CKB 上的产品之后直接为他所用,目前 Lay2 团队 的 ckb.pw 正在做这个方向的努力;另外,像各种先进的密码学技术如 Schnorr 签名、BLS 签名,和 zkSNARKs/zkSTARKs 等,都可以在 CKB 上使用。这也让安全性相关的签名机制、异构跨链、zk rollup 或 BLS rollup 等分层的实验性技术未来更有机会在 Nervos 上实现。
3.CKB 上可以实现可更新合约
合约部署后无法更新一直是区块链开发者的心头之痛,然而因为 CKB 交易中,可以验证 input cell 中 lock script 中的所有权,以及验证 type script 中的生成规则,并且还能通过 cell dep 引用其他的 cell,所以我们能够在 CKB 上产生像是 Type ID 这样的利器。所谓 Type ID 是指某个 Cell 在确定只有某个独一无二的 Type ID 的条件下,持续更新合约,兼顾可升级与确定性,让开发者更灵活地部署并升级自己的合约脚本。
4.可以更灵活的支付手续费
对于 CKB 而言,其实交易的手续费支付具有非常大的灵活性,我们可以通过 Open Transaction 的方式,将各个交易进行构造,这样的情况下我们不但可以更灵活的用各种非原生的代币支付手续费,绕开因原生代币不足而无法支付手续费 ,交易无法成功的窘境,甚至在构造交易时,我们还可以选择让交易的另一方帮你支付手续费。
5.Cell dep 调用的灵活性
如果您曾经在以太坊上进行开发,就会知道在以太坊上无法通过一个交易调用两个先前的合约,因为本质上我们需要调用的是两个合约账户,这时候就必须获得两次的合约授权(Approved),但在 CKB 中,我们可以将许多的合约通过 cell dep 与 type script 被调用,可以在使用更少的资源下实现更高的组合性。
灵活之余,CKB 的确定性让你更安心
除了上面提到了灵活性之外,在 CKB 上的开发者还可以在拥抱灵活编程模型的同时,享有确定性。因为做为 Layer 1 的 Nervos CKB,它只负责执行状态的验证,状态的生成发生在链下,因此它并不会像以太坊那样,开发者的合约需要经过计算才能得到成果。在 CKB 中,我们在链下就能够预期交易的输出状态,让整体交易的执行可以满足「确定性」这个去中心化应用的核心要求。所以,在状态具有确定性的特性下,开发者的合约可以避免被挪作它用,或是受到恶意攻击。这样一来,我们就能够最大程度的确保整体系统的稳定性。
最后,CKB 为大家提供了极大的灵活性和安全性,而对于它的探索还只是刚刚开始,它的很多功能和潜力还远远没有被大家发现。你是否也想进入 CKB 的世界遨游一番?正好,我们为开发者们精心准备了一个 CKB 编程体验课 😜
课程中,除了深入浅出的实操技能外,我们还为大家安排了多位可爱的助教。有兴趣的伙伴们趁着现在赶紧一起加入吧,欢迎扫码报名,或者点击阅读原文了解这门「CKB 编程体验课」。
👇👇👇
👆👆👆开发者们,快来扫码报名!
这篇关于在 CKB 上编程到底有什么样的优势?的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-12-26使用Goldilocks优化Kubernetes资源请求和限制配置指南
- 2024-12-26Canonical Kubernetes 1.32稳定版发布:无缝集群创建与管理
- 2024-12-23在家用实验室或小型生产环境中,搭建Kubernetes集群:在Proxmox虚拟机上运行还是直接用裸机?哪种更适合?
- 2024-12-21Kubernetes生产环境问题排查指南:实战教程
- 2024-12-20使用Encore.ts构建和部署TypeScript微服务到Kubernetes集群
- 2024-12-20Kubernetes:从理念到1.0的历程
- 2024-12-18第28天:Kubernetes中的蓝绿部署讲解
- 2024-12-15从零到Kubernetes安全大师:简化集群安全防护
- 2024-12-15掌握Kubernetes节点调度:污点、容忍、节点选择器和节点亲和性
- 2024-12-14第五天:与容器互动