CKB Programming model in general

This is my study notes about CKB programming model, I tried to introduce some advantages about programming on CKB, but I think this article is more like “something about CKB that interests me”. :rofl: I want to know why you are interested in Nervos CKB, please feel free to comment, it will be very helpful, thank you!

Nervos CKB as Layer 1, is a state-centric architecture in which transactions represent state changes and migrations. CKB provides a unique stateful Turing-complete programming model based on CKB VM and cell model. In this document,I will introduce the CKB Programming model’s some features.

The CKB programming model

If you want to develop based on CKB, it’s recommended that you first understand the programming model. State in CKB is a first-class citizen, states are included in transactions and blocks, and they are synchronized directly between nodes. The CKB programming model consists of three parts:

  • state generation (off-chain)
  • state storage (Cell model)
  • state verification (CKB VM)

In this model, decentralized application logic is split into two parts (generation and verification), which run in different places. State generation logic runs off-chain on the client side, new states are packaged into transactions and broadcasted to the entire network; while state verification takes place on-chain, ensuring the validity of state transitions and creating a trustless system.

Inputs to CKB transactions include references to previous outputs, along with proofs to unlock them. The client includes generated new states as transaction outputs, which are called cells in CKB. Thus the name cell and transaction output are interchangeable. Cells are the primary state storage units in CKB and are assets owned by users that must follow associated application logic specified by scripts.

CKB VM executes these scripts and verifies proofs included in transaction inputs to make sure the user is permitted to use the referenced cells and the state transition is valid under the specified application logic. In this way, all nodes in the network verify that new states are valid and keep these states in custody.

1.Cell model: A generalized version of the UTXO model

The fundamental building block of a Bitcoin transaction is an unspent transaction output or UTXO. UTXO are indivisible chunks of bitcoin currency locked to a specific owner, recorded on the blockchain, and recognized as currency units by the entire network. The data structure is very simple, it only contains two fields:

class TxOut
Amount Value;
Script scriptPubKey;


Every TxOut represents a coin with its own denomination (Yay bit-”Coin”), which is defined by Value . The scriptPubKey is a script which indicates the owner of the coin (and usually refers to the public key of the owner). Only the person who provides the right input that makes the script run successfully can “transfer” the coin to another person.

The focus of Layer 1 is on state, so the design of CKB as Layer 1 should also lay emphasis on state. A state verified and held by CKB is not simply a number ( Value ) as in Bitcoin, but any data that is considered as valuable and recognized by all the actors. The UTXO model of Bitcoin is obviously unable to make this happen. By modifying value to Value a space that can store not just an integer, but also any other data, we have a more generalized “ Value ”, or Cell :

pub struct CellOutput {
pub capacity: Capacity,
pub data: Vec,
pub lock: Script,
pub type_: Option,

In a Cell, the Value field is replaced by capacity and data fields. These are combined to represent a storage space. capacity is not only just the amount of the stored tokens, but it is also a limit on how many data the cell can store. That’s where the name comes from, It is the storage capacity of the cell, while data is where a state described in any given line of bytes is saved.

The Cell model also introduces the concept of lock script and type script which is a brand new verification model, we will see that later.

Overall, The UTXO model makes the ledger history more clear, but its lack of generic state storage makes its already inexpressive scripts harder to use, but the Cell model is a generalized version of the UTXO model. It is a very flexible and creative development experience on CKB.

If you want to learn more about Cell Model, please refer to Cell Model.

2.Lock Script & Type Script: A brand new verification model

CKB is dedicated to a brand new verification model and unlike some other blockchains, CKB provides the freedom to develop CKB scripts back to the whole community.

  1. Lock Script

Every cell has a lock script. The lock script must run when the cell is used as an input in a transaction. A transaction is valid only when all the lock scripts in the inputs exit normally (without exceptions). Since this script runs on inputs, it acts as the lock to control who can unlock and destroy the cell, as well as spend the capacity stored in the cell.

The following is an example lock script code which always exits normally. Anyone can destroy the cell if it uses this code as the lock script.

int main(int argc, char *argv[]) {
return 0;

The most popular way to lock a digital asset is the digital signature created by asymmetric cryptography.
The signature algorithm has two requirements:

  • The cell must contain the information for the public key, so only the real private key can create a valid signature.
  • The transaction must contain the signatures, which usually signs the whole transaction as the message.

2. Type Script

Type script is very similar to lock script, with two differences:

  • Type script is optional.
  • In a transaction, CKB must run the type scripts in both inputs and outputs.

Although we can only keep only one type of script in the cell, we don’t want to mess the different responsibilities in a single script. The lock script is only executed for inputs, so its primary responsibility is protecting the cells. Only the owner is allowed to use the cell as input and spend any assets stored in it.

The type script is intended to establish some contracts on the cells. When you get a cell with a specified type, you can ensure that the cell has passed the verification in the specific code. This code is also executed when the cell is destroyed. A typical scenario of type script is to implement a user-defined token. The type script must run on outputs, so the token issuance must be authorized. overall a type script is used to validate certain rules in the cell transformation phase.

If you want to learn more about CKB’s verification model , please refer to Introduction to CKB Script Programming 1: Validation Model.

3.CKB VM:A real mini computer

CKB VM is a RISC-V instruction set based VM for executing type and lock scripts. But what does that even mean? It means we are (sort of) embedding a real mini computer in CKB, instead of a virtual machine. The benefit of a real computer, is that you can write any logic you want in any language you want.

We can write CKB script codes in JavaScript. How this is possible? Since we have C compiler available, all we did is just take a JavaScript implementation for the embeded system, in our case, duktape, compile it from C to RISC-V binary, put it on chain, then boom, we can run JavaScript in CKB! Since we are working with a real mini computer here, there’s no stopping us from embeding another VM as CKB script to CKB VM, and exploring this VM on top of VM path.

And we can actually expand from this path, we can have JavaScript on CKB via duktape, we can also have Ruby on CKB via mruby, we can even have Bitcoin Script or EVM on chain if we just compile their VM and put it on chain. This ensures CKB VM can both help us preserve legacy and build a diversified ecosystem. All languages should be and are treated equal on CKB, the freedom should be in the hands of blockchain contract developers.

If you want to learn more about CKB VM , please refer to RFC:CKB-VM

4.UDT:First-class asset

One common use in existing blockchains, is to issue new tokens with special purpose/meaning from the token issuer. In Ethereum, we call those ERC20 tokens.To distinguish from ERC20, we call the tokens issued in CKB user defined token , or UDT for short.

What is first-class asset?
The concept of first-class asset is actually derived from the first-class function. A first-class Asset is an encrypted Asset that is directly owned by the user and can be manipulated directly.

Why UDT is first-class asset?
While Ethereum has a unique storage space for each contract account, CKB spreads data among multiple cells. A cell’s lock & type script then tells which account the cell belongs to, as well as how you can interact with the cell. In CKB we have a new design to store the balances of UDT users:

  1. A special type script denotes that the cell stores UDTs.
  2. The first 4 bytes of the cell data contains the amount of UDTs in current cell.

This design has several implications:

  • The storage cost for a UDT cell is always constant, it is irrelevant to the amount of UDTs stored in the cell.
  • A user can transfer either all or part of the UDTs in a cell to others
  • In practice, there might be numerous cells containing the same UDTs.
  • The lock script used to guard a UDT is decoupled from the UDT itself.

Each token user then keeps their UDTs in their own cells. They are responsible for providing the storage space for the UDTs, and ensure their own tokens are secure. This way UDTs can truly belong to each individual UDT user unlike ERC20 which stores all token users’ balances in the ERC20 contract’s storage space and as we know ERC20 contracts have security vulnerability.

The economic model of CKB focuses on the incentives of state storage. Users are required to pay for state storage of their assets on the blockchain and bear cost proportional to the amount of data stored and length of storage time. This resolves an issue we see when implementing ‘storage rent’ in Ethereum ERC20 contracts for example- when all asset states for all users are mixed, it is difficult to provide each user the ability to pay for storage of only their assets on the blockchain.

If you want to learn more about first-class asset, please refer to First-class Asset.

5.Type ID:Provide the balance between Upgradability vs. Determinism

In the blockchain space, there’s a pair of issues that everyone has to pick sides:

The conflicts between Upgradability and Determinism

Upgradability:Can I upgrade a smart contract after it’s deployed on the blockchain? Suppose a smart contract gets widely adopted, then all of a sudden, someone notices a bug in the smart contract(sadly this will always happen in our industry), can we upgrade the smart contract to a fixed version without affecting all the users?

Determinism:This one has 2 parts:

  • Determinism A: if I pick a smart contract to guard my tokens, will my tokens stay safe(could be unlocked by me and only by me) in the future?
  • Determinism B: if I sign a transaction now, and send it later, will my transaction still be accepted by the blockchain?

Note that a secure blockchain has more deterministic requirements than those mentioned here. I’m only including properties that relate to the discussed problem here.

If we think about it, we could find that there’re always conflicts between upgradability and determinism:

  • If a smart contract could be upgraded, it might have different behaviors, hence enabling an attacker to unlock a cell, or disabling unlocking from the owner himself/herself.
  • If a smart contract could be upgraded, an already signed transaction might run into different behaviors, resulting it be rejected by the blockchain.

Historically, there is only one side you can pick, and most existing blockchains have picked the side of determinism. The “code is law” idea thus becomes very famous in the blockchain space.

But we all know software design is all about tradeoffs. Given certain situation, it might make sense to sacrifice slight determinism, in exchange for the ease of upgradability,so we have implemented a unique script, named a type ID script . This feature is totally optional in CKB, you can perfectly practice “code is law” principle in CKB like in other blockchains and you can balance the upgradability and determinism. We are just hoping this unique feature will provide new possibilities for people who really need it.

If you want to learn more about Type ID please refer to Introduction to CKB Script Programming 6: Type ID.

6.Advanced Duktape:write CKB script codes in JavaScript

We can have JavaScript on CKB via duktape because of the powerful CKB VM. We can not only have some single pieces of code with very simple logics, but we can parse CKB data structures, put external libraries in the script and so on.Our CKB core developer Xuejie has written an article about how to implement:Introduction to CKB Script Programming 7: Advanced Duktape Examples

The article displays how to create a duktape-powered CKB script with the following requirements:

  • External library dependency
  • Serialization/Deserialization of CKB data structures
  • Hashing

It’s very useful examples for people who want to develop JS projects and you can have a streamlined CKB script development experience via JavaScript & duktape.

7.Debug:Support GDB & REPL based Development/Debugging

Debugging a CKB script is not so different from debugging your everyday program.The first solution to CKB script debugging, works with compiled languages such as C, Rust, etc. Perhaps you are used to writing C programs, and GDB is your best friend. You are wondering if debugging C programs with GDB is possible, and the answer, of course, is: yes, you can definitely debug your CKB script written in C via GDB.

However, GDB is only one part of the story in modern software development. Dynamic languages have largely taken the landscape, and many programmers are used to REPL baesd development/debugging workflow. This is totally different from GDB in a compiled languages, basically what you get is a running environment, and you can type in any code you want to interact with the environment, getting different results. CKB also has support for this type of development/debugging workflow.

If you want to learn more how to debug CKB scripts, please refer to Introduction to CKB Script Programming 5: Debugging.

8.Embrace the WebAssembly ecosystem

RISC-V is actually a lower level of abstraction than WebAssembly, we can port existing WebAssembly programs, and run them on CKB VM directly. This way, we can enjoy the flexibility and stability provided by RISC-V, while also embracing the WebAssembly ecosystem.

Running WebAssembly programs in CKB VM actually has more benefits running this way than directly using a WebAssembly VM:

  • In the CKB environment, however, we can attach any environment functions as we like, hence supporting all WebAssembly programs which are targeting different blockchains. What’s more, we can use imports as we like to introduce new features to an existing WebAssembly programs, since the import functions are shipped together with the WebAssembly program, CKB itself doesn’t have to do anything to support this, all the magic happens right within a single CKB script. For a WebAssembly powered blockchain, those environment functions are most likely to be fixed and part of the consensus rules, you cannot introduce new ones as you wish. Similarly, this tranformation based workflow on CKB will make it far easier to support new WebAssembly features, such as garbage collection, or threading, it really is just a matter of shipping the support features you need as part of your CKB script, there’s no need to wait another 6 months for the next hard fork when a WebAssembly virtual machine gets updated, if it’s updated.
  • It’s easy to implement
  • Building WebAssembly on RISC-V feels more natural, since WebAssembly abstracts at a higher level with many high level features, such as higher level contrl flows, garbage collection, etc. RISC-V, on the other hand, really emulates what a real CPU can do, it is a very thin layer on top of the actual CPU running inside of the computer. So while both directions are possible indeed, certain features are easier to implement in the WebAssembly on RISC-V direction, while roadblocks might sit in front of you in the RISC-V on WebAssembly direction.
  • One alternative example is EVM, EVM has been advocating turing complete for years, but the sad truth is that it’s close to impossible to build arbitrary complicated algorithsm on EVM: either the coding part is too difficult or gas consumption will be unreasonable. People have to come up with all kinds of hacks so as to introduce latest algorithms on EVM, we can only have reasonable blake2b algorithms in EVM when Istanbul hardfork lands. What about many other algorithms?

We try to find the minimal layer on top of this generation’s CPU architecture, and RISC-V is the most transparent model we can expose to the blockchain world while ensuring security and performance. Any different models, such as WebAssembly, EVM, etc., should be one layer on top of the RISC-V model, and can be naturally implemented via the RISC-V model. The other direction, however, might not feel so smooth at all.

Besides, we have a new project that could be used to generate performant WASM program s, you can see how it works in Introduction to CKB Script Programming 8: Performant WASM.

Developer community

We have launched the Nervos Grants Program to empower innovation and development and support the growth of a diverse and thriving ecosystem.

The goal of the program is to attract talent to research and build the necessary tooling for developing solutions around Nervos, and to incentivize developers and projects who are willing and passionate about working on these solutions.

Our long term vision is to be fully decentralized and community-led. Achieving this means bootstrapping individuals, projects and teams who want to make significant contributions toward building out our infrastructure.

  • Visit Nervos Talk for a list of the types of submissions we’re hoping to see. If you have the interest, experience and skills to deliver on any project within the scope of the grant categories currently open, we invite you to submit a proposal for funding and join us in building out the Nervos Ecosystem and Common Knowledge Base (CKB).
  • As with everything we do, the process and program will be fully transparent. From evaluating applications to voting for the strongest submissions, every step of the program will be open for the community members to review and provide feedback.



感谢 @Zengb 的学习笔记,非常有帮助。以下是本文的中文翻译~

一文了解 CKB 编程模型

Nervos CKB 是一个以状态为中心的 Layer 1 底层架构,其中交易表示状态的更改和迁移。CKB 提供了一种独特的基于 CKB VM 和 Cell 模型的有状态的图灵完备编程模型。在本文中,我们将向你介绍 CKB 编程的基本内容。

CKB 编程模型

如果您想要在 CKB 上进行开发,那么您首先应该要理解它的编程模型。CKB 中的状态是一等公民(First-Class Citizen),状态包含在交易和区块中,它们直接同步在节点之间。CKB 的编程模型由三部分组成:

  • 状态生成(链下)
  • 状态存储(Cell 模型)
  • 状态验证(CKB VM)

在这个模型中,去中心化的应用逻辑被分为两个部分(生成和验证),分别在不同的地方运行。状态生成发生在客户端的链下,新的状态被打包成交易并广播到整个网络;状态验证发生在链上,它会确保状态转换的有效性并创建一个去信任的系统(trustless system)。

CKB 交易的 inputs 包括对之前 outputs的引用,以及能够解锁它们的证明。客户端将生成的新状态作为交易 outputs,在 CKB 中称为 cell。因此,cell 和交易输出的表述是可以互换的。 Cell 是 CKB 中的主要状态存储单元,资产所有权归用户所有,并且必须遵循脚本指定的相关应用程序逻辑。

我们在 CKB VM 中执行脚本(后文将做具体介绍)并验证交易输入中包含的证明,以确保用户可以使用这些引用的 cell,并且在指定的应用程序逻辑下状态转换是有效的。通过这种方式,网络中的所有节点都可以验证新状态是有效的,并保留这些状态。

1.Cell 模型:通用化的 UTXO 模型

Bitcoin 把整个账本分割保存在了一个个 UTXO 里面,UTXO 是未花费交易输出(Unspent Transaction Output)的简写,它被锁定在特定的所有者手中,记录在区块链上,并被整个网络识别为货币单位。它的数据结构非常简单,只包含两个字段:

class TxOut
Amount Value;
Script scriptPubKey;

每一个 TxOut 代表了一个硬币并且有自己的命名,这是由 Value 定义的, scriptPubKey 是一段表示这个硬币的所有者是谁的脚本(通常包含了所有者的公钥),只有能提供正确的参数使这个脚本运行成功的人,才能把这个硬币「转让」给另外一个人。


Layer 1 的关注重点在状态,以 Layer 1 为设计目标的 CKB 设计的关注点很自然就是状态。CKB 想要验证和长久保存的状态,不仅仅是像在比特币中那样简单的数字( Value ),而是任何人们认为有价值的、经过共识的数据,Bitcoin 的交易输出结构满足不了这个需求。只需要将 Value 一般化,把它从一个存放整数的空间变成一个可以存放任意数据的空间,我们就得到了一个更加一般化的「 Value 」或者叫 Cell:

pub struct CellOutput {
pub capacity: Capacity,
pub data: Vec<u8>,
pub lock: Script,
pub type_: Option<Script>,

在 Cell 里面, Value 变成了 capacitydata 两个字段,这两个字段共同表示一块存储空间, capacity 不仅仅只是存储 Token 的数量,也能表示 cell 可以存储数据数量的限制,这就是名字的由来,它是 cell 能够存储的容量限制, data 则是保存状态的地方,可以写入任意的一段字节。

Cell 模型是一个全新的模型,引入了 lock scripttype script 的概念,我们将在后面提到。

总的来说,UTXO 模型让账簿的历史记录更加清晰,但是它缺乏通用的状态存储,这会让它原本就缺乏表现力(inexpressive)的脚本更加难以使用。Cell 模型是 UTXO 模型的一个通用版本,它是 CKB 上非常灵活和具有创造力的部分。

如果你想要了解更多关于 Cell 模型的内容,欢迎查阅《理解 CKB 的 Cell 模型》。

2.锁定脚本 & 类型脚本:一个全新的验证模型

CKB 是一个全新的验证模型,与其它一些区块链不同,CKB 为整个社区提供了开发 CKB 脚本的自由。

1. 锁定脚本

每个 Cell 都有一个锁定脚本。当交易中的 Cell 被以输入的形式使用时,锁定脚本必须执行。交易只有在所有的输入中锁定脚本都正常(执行并)退出时(没有例外)才有效。因为脚本在输入上运行,所以它可以扮演锁的角色来控制谁可以解锁或者销毁 Cell,以及花费储存在 Cell 中的容量。

以下是一个总是可以正常(执行并)退出的锁脚本的代码示例。如果使用这段代码作为锁脚本,那么任何人都可以销毁这个 Cell。

int main(int argc, char *argv[]) {
return 0;



  • Cell 必须要包含公钥的信息,所以只有真正的私钥可以创建有效的签名;
  • 交易必须包含签名,而且通常以整个交易作为消息去签名。



  • 类型脚本是可选的;
  • 在任一交易中,CKB 必须在输入和输出端都运行类型脚本。

虽然我们只能在 Cell 中维持一种脚本,但我们不会想要在一个单一的脚本中扰乱(脚本)不同的职责。锁定脚本只为输出执行,所以他的首要任务是保护 Cell。只有所有者可以以输入的形式使用 Cell,以及花费储存于其中的通证。

类型脚本的目的是在 Cell 上建立合约。当你得到一个特殊类型的合约时,你可以确定 Cell 已经在特定代码中通过验证。同时这个代码也会在 Cell 被销毁时被执行。典型的类型脚本场景是用户自定义 Token,这种类型脚本必须在输出上运行,所以通证的发行必须被授权。总的来说,类型脚本是在 cell 转换阶段中用于验证某些规则的。

如果你想要了解更多关于 CKB 验证模型的内容,欢迎查看《CKB 脚本编程简介第一弹: 验证模型》。

3.CKB VM:一台真正的迷你电脑

CKB VM 是一个基于 RISC-V 指令集的 VM,用于执行类型脚本和锁脚本。这意味着什么呢?这意味着我们(在某种程度上)在 CKB 中嵌入了一台真正的迷你计算机,而不是一台虚拟机。真正计算机的好处是,你可以使用任何语言编写任何你想编写的逻辑。

我们可以用 JavaScript 编写 CKB 脚本代码。这是怎么实现的呢?那是因为我们有 C 编译器可用,我们所做的只是采用了一个 JavaScript 实现的嵌入式系统,通过 duktape 从 C 编译成 RISC-V 二进制,并放在区块链中,然后 boom,我们就可以在 CKB 上运行 JavaScript! 因为我们在这里使用的是一台真正的迷你计算机 ,所以我们可以将另一个 VM 作为 CKB 脚本嵌入到 CKB VM 中,并在 VM 路径上探索这个 VM。

我们还可以用这个方法进行扩展,我们可以在 CKB 上通过 duktape 使用 JavaScript,也可以通过 mruby 使用 Ruby,我们甚至可以在 CKB 上使用比特币脚本或 EVM 如果我们只是编译它们的 VM 和把它放在链上。这确保了 CKB VM 既能帮助我们保存自身的优势,又能建立一个多样化的生态系统。 在 CKB 中,所有的语言都应该被平等对待,自由应该被掌握在区块链智能合约开发者的手中

如果你想要了解更多关于 CKB VM 的内容,欢迎查看《RFC:CKB-VM》。

4.UDT:First-class asset

现有区块链的常见用途是向 Token 发行方发行具有特殊用途/意义的新 Token。在以太坊,我们称之为 ERC20 代币。为了区别于 ERC20,我们将 CKB 上发行的 Token 称为用户自定义代币( user defined token ,简称 UDT)。

什么是 First-Class Asset?

First-Class Asset 的概念实际上来自 First-Class Function。First-Class Asset 是用户直接拥有并可以直接操作的加密资产。

为什么 UDT 是 First-Class Asset?

Ethereum 是为每个智能合约帐户提供了独特的存储空间,而 CKB 是在多个 cell 之间传播数据。Cell 的锁定脚本和类型脚本决定了该 cell 属于哪个帐户,以及如何与 cell 交互。在 CKB 中,我们有一个新的设计来存储 UDT 用户的余额:

  1. 用一个特殊的类型脚本来表示该 cell 存储的是 UDT。
  2. Cell data 的前 4 个字节包含了当前 cell 中 UDT 的数量。


  • UDT cell 的存储成本总是恒定的,它与 cell 中存储的 UDT 数量无关。
  • 用户可以将 cell 中的所有 UDT 或部分 UDT 转移给其他用户
  • 实际上,可能有多个 cell 含有相同的 UDT。
  • 用于保护 UDT 的锁定脚本与 UDT 本身解耦。

每个 Token 用户将其 UDT 保存在自己的 cell 中,Cell 负责为 UDT 提供存储空间,并确保它们自己的 Token 是安全的。通过这种方式,UDT 可以真正地属于每个单独的 UDT 用户,而不像 ERC20 那样将所有 Token 用户的余额都存储在 ERC20 合约存储空间中,而 ERC20 合约存在某些安全漏洞

CKB 的经济模型关注状态存储激励问题。用户在区块链上保存状态不仅需要支付写入费用,而且应该承担与存储时间成正比的存储成本。这解决了我们在 Ethereum ERC20 合约中实现「存储租金」时遇到的问题,例如,如果用户的资产状态混合在一个地方保存,那么如何让每个用户仅支付存储自己资产的成本将是一个问题。

如果你想要了解更多关于 First-class asset 的内容,欢迎查看《First-class Asset

5.Type ID:提供可升级性和确定性之间的平衡



可升级性:在一个智能合约部署在区块链上之后,我还能升级它吗?假设一个智能合约得到了广泛采用,然后突然有人在这个智能合约中发现了一个 bug(遗憾的是,这样的情况在区块链行业总是会发生),我们能否在不影响所有用户的情况下,将智能合约升级到一个修复完成的版本呢?


  • 确定性 A:如果我选择一个智能合约来保护我的 token,那么我的 token 在未来也会安全吗?(可以由我解锁,且只能由我解锁)
  • 确定性 B:如果我现在签名了一笔交易,然后稍后再发送它,我的交易还会被区块链接受吗?



  • 如果一个智能合约可以升级,那它可能具有不同的行为,从而使攻击者能够解锁这个 cell,或者禁止 token 所有者去解锁这个 cell。
  • 如果一个智能合约可以升级,那么一笔已经签名的交易可能会(在升级前后)执行不同的行为,从而被区块链拒绝。


但是我们都知道软件的设计是一个权衡的过程。在特定情况下,牺牲一些确定性来换取可升级性带来的便利是有意义的。因此,我们实现了一个独特的脚本: type ID script。 在 CKB 上,这个功能完全是可选的,你可以像在其它区块链中一样,在 CKB 上完美地践行「代码即法律」的原则,并且可以提供可升级性和确定性之间的平衡。我们只是希望这个独特的功能,能为那些真正需要它的人提供新的可能性。

如果你想要了解更多关于 Type ID 的内容,欢迎查看《CKB 脚本编程简介[6]:Type ID

6.Duktape 高级编程:用 JavaScript 编写 CKB 脚本

得益于强大的 CKB VM,我们可以在 CKB 上通过 duktape 使用 JavaScript。我们不仅可以有一些逻辑非常简单的代码片段,还可以解析 CKB 数据结构,在脚本中放置外部库等等。我们的 CKB 核心开发人员 Xuejie 写了一篇关于如何实现的文章:CKB 脚本编程简介[7]:Duktape 高级编程

这篇文章中演示了如何创建一个 CKB 脚本项目:duktape-powered,这个项目有以下需求:

  • 外部库依赖
  • CKB数据结构的序列化/反序列化
  • 进行哈希计算

对于想要开发 JS 项目的人来说,这是一个非常有用的例子,你可以通过 JavaScript 和 duktape 获得精简的 CKB 脚本开发体验。

7.调试:支持基于 GDB 和 REPL 的开发/调试

调试 CKB 脚本和你日常调试程序并没有太大区别。CKB 脚本调试的第一种方案,通常适用于 C、Rust 等编程语言。也许你已经习惯了写 C 的程序,而 GDB 也是你的好搭档。你想知道是不是可以用 GDB 来调试 C 程序,答案当然是:Yes!你肯定可以通过 GDB 来调试用 C 编写的 CKB 脚本。

然而,GDB 仅仅是现代软件开发中的一部分。动态语言在很大程度上占据了主导地位,很多程序员都使用基于 REPL 的开发/调试工作流。 这与编译语言中的 GDB 完全不同,基本上你需要的是一个运行的环境,你可以输入任何你想要与环境进行交互的代码,然后得到不同的结果。CKB 也会支持这种类型的开发/调试工作流。

如果你想要了解更多关于如何调试 CKB 脚本的内容,欢迎查看《CKB 脚本编程简介[5]:调试

8.拥抱 WebAssembly 生态系统

与 WebAssembly 相比,RISC-V 实际上是一个更低层次的抽象,我们可以移植现有的 WebAssembly 程序,并直接在 CKB VM 上运行它们。通过这种方式,我们可以拥有 RISC-V 提供的灵活性和稳定性,同时也可以拥抱 WebAssembly 生态系统。

在 CKB VM 中运行 WebAssembly 程序实际上比直接使用 WebAssembly 虚拟机有更多的好处:

  • 在 CKB 环境中,我们可以附加任何我们喜欢的环境功能,从而支持所有针对不同区块链的 WebAssembly 程序。更重要的是,我们可以使用导入,因为我们想要向现有的 WebAssembly 程序引入新功能,因为导入功能是与 WebAssembly 程序一起提供的,所以 CKB 本身不需要做任何事情来支持这一点,所有的神奇之处都发生在一个 CKB 脚本中。而对于支持区块链的 WebAssembly,这些环境功能很可能是固定的,并且是共识规则的一部分,不能随意引入新的环境功能。同样的,这个基于 CKB 的转型工作流能够让它更容易地支持新的 WebAssembly 特性,比如垃圾回收或线程,它实际上只是将所需的支持功能作为 CKB 脚本的一部分即可,所以当 WebAssembly 虚拟机得到更新时(如果已更新),我们无需再等待 6 个月来进行下一次硬分叉。
  • 易于实现:
    • 在 RISC-V 上构建 WebAssembly 会让人感觉更自然,因为 WebAssembly 在更高的层级上抽象了许多高级特性,例如更高级别的控制流,垃圾回收等。另一方面,RISC-V 模拟了一个真正的 CPU 可以做什么,这是在计算机内部运行的实际 CPU 之上非常薄的一层。因此,虽然这两个方向都是有可能的,但是确定(certain)的功能在 RISC-V 方向的 WebAssembly 中更容易实现,而在 WebAssembly 方向的 RISC-V 中可能会遇到障碍。
    • 另一个可供选择的方案是 EVM,多年来 EVM 一直在倡导图灵完备的解决方案,但可惜的是,在 EVM 上构建任意复杂的算法几乎是不可能的:要么编码部分太困难,要么 gas 消耗不合理。为了在 EVM 上引入最新的算法,人们不得不想出各种各样的破解方法,当伊斯坦布尔硬分叉发生时,我们只能在 EVM 中运用合理的 blake2b 算法。那么其他的算法呢?

我们试图在这一代的 CPU 架构上找到最小的层,而 RISC-V 是我们可以向区块链世界公开的最透明的模型,同时确保安全性和性能。任何不同的模型,例如 WebAssembly、EVM等,都应该是 RISC-V 模型之上的层,并且可以通过 RISC-V 模型自然地实现,但是,另一个方向可能就不那么顺利了。

此外,我们有一个新的项目可以用来生成 高性能的 WASM 程序, 你可以查看并了解详情:《CKB 脚本编程简介[8]: 高性能 WASM


看到这里,你们是否对 CKB 的编程模型有了初步的了解,或者有了一些很好的想法?今年年初,我们已经发布了 Nervos Grants 计划来促进 CKB 上的创新和发展,并支持多样化和繁荣的生态系统发展。并成立了 3000 万美元 的基金,用于资助开发者在 Nervos 上的开发。

Grants 计划的目标是吸引更多有才华的人围绕 Nervos 开发解决方案,来研究和建立必要的工具,并激励那些有意愿和有激情致力于这些解决方案的开发人员和项目。

我们的长期愿景是完全地去中心化和社区主导。要实现这一点意味着我们需要激发并引导那些希望为构建 Nervos 基础设施做出重大贡献的个人、项目和团队。

您可以访问 Nervos Talk 来了解 Grants 计划详情,并获取我们希望看到的提交类型列表。如果你也对 Nervos 项目感兴趣,如果你也有好的 idea、经验和技能,我们邀请您提交一份资助提案,和我们一起构建 Nervos 生态系统和共同知识库(Common Knowledge Base,CKB)。

和我们做的每一件事一样,Grants 计划过程和程序将是完全透明的。从评估申请,到投票选出最强的提交,项目的每一步都将向社区成员开放,让他们进行审查并提供反馈。

更多关于 Grants 的信息,欢迎查看: