【RFC002--翻译】Nervos CKB: A Common Knowledge Base for Crypto-Economy ; Nervos CKB:加密经济的共同知识库

欢迎提出来,或者可以直接在Nervos communty的Github上Pull request!


Nervos CKB: A Common Knowledge Base for Crypto-Economy 加密经济的共同知识库


Nervos is a layered crypto-economy network. Nervos separates the infrastructure of a crypto-economy into two layers: a verification layer (layer 1) that serves as a trust root and smart custodian, and a generation layer (layer 2) for high-performance transactions and privacy protection.
This document provides an overview of the Nervos Common Knowledge Base (CKB), a public permissionless blockchain and layer 1 of Nervos. CKB generates trust and extends this trust to upper layers, making Nervos a trust network. It’s also the value store of the Nervos network, providing public, secure and censorship-resistant custody services for assets, identities and other common knowledge created in the network.
Nervos是一个分层的加密经济网络。Nervos将加密经济的基础设施分做两层: 验证层(Layer1)能够作为信任的根源以及智慧监管;生成层(Layer2)则是作为高速交易以及隐私保护。
这份文件提供一个关于Nervos Common Knowledge Base(CKB)的公有认许制区块链以及Narvos的Layer1概述。CKB产生了信任,并且将这份信任延伸至更上层,使得Nervos产生一个信任的网络。这也是Nervos网络中的价值商店,提供公开、安全,以及为在网络中所创建的资产、身分和其他公共知识创造了抗审查的托管服务。

Contents 内容

  1. Motivation 动机
  2. Overview 概述
  3. Consensus 共识
  4. Programming Model 编程模型
    -State Generation and Verification 状态生成与验证
    -VM 虚拟机
    -Transaction 交易
  5. Economic Model 经济模型
  6. Network 网络
  7. Summary 总结
  8. References 文献
  9. Appendix 附录

1.Motivation 动机

We want a peer-to-peer crypto-economy network.
In such a network, people can not only collaborate but also have incentives to do so. We need the ability to define, issue, transfer, and own assets in a peer-to-peer network to create such incentives. Blockchain technology brings us the last piece of the puzzle.
Bitcoin[1] was the first public permissionless blockchain, designed to be used solely as peer-to-peer cash. Ethereum[2] extends the use case of blockchain to create a general purpose trust computing platform on which people have built all kinds of decentralized applications. The booming applications on the Bitcoin and Ethereum networks have proven the concept of the future crypto-economy. However, these networks also suffer from the notorious scalability problem, their transaction processing capability cannot scale with the number of participants in the network, which severely limits their potential.

The blockchain community has proposed many scalability solutions in recent years. In general, we can divide these solutions into two categories, on-chain scaling and off-chain scaling. On-chain scaling solutions are those that try to scale at the same layer where consensus runs. The consensus process is the core of a blockchain protocol, in which nodes exchange network messages and reach agreement eventually. A consensus is slow almost by definition, because message exchange on a public and open network is slow and uncertain, nodes must wait and retry to reach agreement in the consensus process.

To scale at this layer, we can either “scale up” by increasing the processing ability and network bandwidth of nodes (but sacrifice decentralization due to high hardware and infrastructure costs), or “scale out” by sharding. The idea of sharding is to divide nodes into many small “shards”, and ask each shard to process only a fraction of network transactions. Sharding is widely adopted by Internet giants, as they face the same scalability issues when serving millions of users. However, sharding is well known for the complexity of shard coordination and cross-shard transactions, which even in a trusted environment, leads to performance degradation as the number of shards grows.
为了要达到此层的扩展,我们可以藉由增加进程的能力以及节点网络带宽而增加扩展性(但是牺牲去中心化,因为硬件和基础设施的成本);或者也可以透过分片的方式向外扩展。分片的概念是将节点分成很多个小分片,并要求每个分片只处理一部分的网络交易。分片的概念已经被许多互联网巨头所使用,由其当他们服务数百万名使用者,并同样面临到扩展性的问题时。然而,分片以分片协调(shard coordination)和跨片交易( cross-shard transactions)的复杂性闻名,即使在可信任的环境中,当分片数量成长的时候,也会导致其性能降低。

In contrast, off-chain scaling solutions acknowledge the inherent complexity of the consensus process. They recognize that consensus within different scopes incur different costs, and the global consensus created by a public permissionless blockchain is the most expensive consensus. While it is hard to scale a global consensus, we can use it wisely. Most transactions between two or more parties don’t need to be known by every node in the network, except when they are securely settled; in other words, when users want to turn their transactions into common knowledge of the network. This network scales by offloading most of the work to upper layers, with no limit on scalability. Processing transactions off-chain also brings additional benefits, such as lower latency and higher privacy.

While we agree with the general ideas of off-chain scaling, we have found that there is no existing blockchain designed for it. For example, though the lightning network is one of the earliest explorations in off-chain scaling, it has taken years to launch its testnet and is still far from mass-adoption due to the limitations of the underlying Bitcoin protocol. Ethereum provides powerful programming ability, but its computation-oriented economic model doesn’t fit well with off-chain scaling. Because off-chain participants handle most of the computation, what is required is a blockchain that can keep their assets in secure custody and move assets according to the final state of their computation. The computation-oriented design of Ethereum also makes it difficult to execute transactions in parallel, which is an impediment to scalability.

The economic models of current blockchains also face challenges. With more users and applications moving to blockchain platforms, the amount of data stored on blockchains also increases. Current blockchain solutions are concerned more with the cost of consensus and computation, and allow a user to pay once and have their data occupy full nodes’ storage forever. Cryptocurrency prices also are highly volatile, and users may find it difficult to pay high transaction fees as the price of a cryptocurrency increases.
We propose Nervos CKB, a public permissionless blockchain designed for a layered crypto-economy network.
最近的区块链经济模型也面临挑战。随着许多使用者和应用者迁移到区块链平台,储存在区块链上的数据总数也在增加。最近的区块链解决方案更关注在共识和计算的成本,而且允许使用者只须付一次的费用就能够永久的在全节点上存储资料。加密货币的价格也非常地不稳定,当加密货币价格上涨时,用户可能因此会难以负担高额的手续费。我们推出Nervos CKB,一个为分层的加密经济网络所设计的公共无许可制的区块链。

2.Overview 概覽

Nervos CKB (Common Knowledge Base) is a layer 1 blockchain, a decentralized and secure layer that provides common knowledge custody for the network. Common knowledge refers to states that are verified by global consensus. Crypto-assets are an example of common knowledge.
Nervos CKB(Common Knowledge Base,公共知识库)是一个layer1的区块链,一个区中心化的安全层,提供给网络中的公共知识托管服务。公共知识是指经过全球共识验证的状态。加密资产是一个公共数据库的例子。

In Nervos, the CKB and all layer 2 protocols work together to serve the crypto-economy. CKB (or layer 1) is where state is stored and defined, and layer 2 is the generation layer (or computation layer, these two terms are interchangeable) that processes most transactions and generates new states. Layer 2 participants submit newly generated states to the CKB eventually at the time they deem necessary. If those states pass the corresponding verification performed by nodes in a global network, the CKB stores them in a peer-to-peer node securely.

The layered architecture separates state and computation, providing each layer more flexibility and scalability. For example, blockchains on the generation layer (layer 2) may use different consensus algorithms. CKB is the lowest layer with the broadest consensus and provides the most secure consensus in the Nervos network. However, different applications might prefer different consensus scopes and forcing all applications to use CKB’s consensus would be inefficient. Applications can choose the appropriate generation methods based on their particular needs. The only time these applications will need to submit states to CKB for broader agreement is when they need to make these states common knowledge that has been verified by the CKB’s global consensus.

Possible state generation methods include (but are not limited to) the following:

  • Local generators on the client: Generators run directly on the client’s devices. Developers can implement the generator in any programming language.

  • 客户端上的本地生成器:生成者直接运行他们的客户端装置。开发者可以使用任何一种编程语言来配置生成器。

  • Web services: Users may use traditional web services to generate new states. All current web services may work with CKB in this way to gain more trust and liquidity for the generated states. For example, game companies may define in-game items as assets in CKB, the game itself functions as a web service that generates game data, which is then verified and stored in CKB.

  • 网络服务:用户可能会使用传统的网络服务来生成新的状态。全部最近的网络服务可能会和CKB共同来运作,并以这种方式来为生成的状态促进更多的信任和流动性。例如,游戏公司可定义游戏中的物品是CKB中的资产,而游戏本身就是一个网络服务,且他会生成可以被验证并且储存在CKB中的游戏资料。

  • State channels: Two or more users may use peer-to-peer communication to generate new states.

  • 状态通道:两者或者更多的使用者,可能会使用点对点的通讯服务来生成新状态。

  • Generation chains: A generation chain is a blockchain that generates new states and stores them in CKB. Generation chains may be permissionless blockchains or permissioned blockchains. In each generation chain, nodes reach consensus in smaller scopes, providing better privacy and performance.

  • 生成链(Generation chains):一个生成链是一个可以生成新状态并且储存他们在CKB中的区块链。生成链可以是无默许制或者默许制的区块链。在个别的生成链中,节点可以在更小范围内达成共识,并提供更好的隐私和性能。

Figure 1. Layered Architecture

CKB consists of a Proof-of-Work based consensus, a RISC-V instruction set based virtual machine, a state model based on cells, a state-oriented economic model, and a peer-to-peer network. The Proof-of-Work based consensus makes the CKB a public and censorship-resistant service. The combination of CKB VM and the Cell model creates a stateful Turing-complete programming model for developers, making state generation (or layer 2) on CKB practical. The CKB economic model is designed for common knowledge custody and long-term sustainability. The CKB peer-to-peer network provides secure and optimal communication between different types of nodes.

3.Consensus 共识

CKB consensus is an improved Nakamoto consensus based on Proof-of-Work, that aims to achieve openness, correctness and high performance in distributed environments with network delay and Byzantine node faults.
Permissionless blockchains run in open networks where nodes can join and exit freely, with no liveness assumptions. These are severe problems for traditional BFT consensus algorithms to solve. Satoshi Nakamoto introduced economic incentives and probabilistic consensus to solve these problems. Nakamoto consensus in Bitcoin uses blocks as votes, which takes longer (up to 10 minutes to an hour) to confirm transactions and leads to an inferior user experience.

CKB consensus is a Nakamoto consensus variant, which means it allows nodes to join and exit the network freely. Every node can participate in the consensus process either by mining (running a specific algorithm to find the Proof-of-Work) to produce new blocks, or by verifying new blocks are valid. CKB uses an ASIC-neutral Proof-of-Work function, with the goals of distributing tokens as evenly as possible and making the network as secure as possible.
Correctness includes eventual consistency, availability, and fairness. Eventual consistency guarantees every node sees an identical copy of state. Availability makes sure the network responds to users’ requests within a reasonable time. Fairness ensures mining nodes get fair returns for their efforts to keep the network functioning securely.

High performance includes transaction latency, the time between the submission of a request and the confirmation of its execution results, and transaction throughput, the number of transactions the system is capable of processing per second. Both of these measures depend on block time, which is the average time between two consecutive blocks.
Please check the CKB Consensus Paper for more details.


4.Programming Model 编程模型

CKB provides a stateful Turing-complete programming model based on CKB VM and cell model.
CKB提供了基于CKB 虚拟机和Cell模型的有状态图灵完备的编程模型。

Bitcoin Ethereum CKB
Instruction Set Script EVM RISC-V
Cryptographic Primitive Opcode Precompile Assembly
Stateful No Yes Yes
State Type Ledger General General
State Model UTXO Account Cell
State Verification On-chain On-chain On-chain
State Generation Off-chain On-chain Off-chain

The CKB programming model consists of three parts:

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


  • 状态生成(鏈下)
  • 状态验证(CKB 虚拟机)
  • 状态存储(Cell模型)

In this model, decentralized application logic is split into two parts (generation and verification), running 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. CKB transactions have an inputs/outputs based structure like Bitcoin. Transaction inputs are 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. 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 inputs to make sure the user is permitted to use referenced cells and the state transition is valid under specified application logic. In this way, all nodes in the network verify that new states are valid and keep these states in custody.

State in CKB is a first-class citizen, states are included in transactions and blocks and synchronized directly among nodes. Although the programming model is stateful, scripts running in CKB VM are pure functions with no internal state, which makes CKB scripts deterministic, conducive to parallel execution, and easy to compose.

4.1 State Generation and Verification 状态生成与验证

Decentralized applications on Nervos separate the generation and verification of state. While these processes occur in different places, CKB provides the additional flexibility to utilize different algorithms for state generation and verification.

Utilizing the same algorithm on both generation and verification sides is a straightforward choice that works for general problems. In this model, the same algorithm has two implementations, one that runs off-chain in any execution environment targeted by the application, and the other one runs on-chain in CKB VM. New states are generated off-chain with this algorithm (based on previous states and user inputs), packaged as a transaction, and then broadcasted to the network. CKB nodes run this same algorithm on-chain, provide it the same previous states and user inputs, and then verify the result matches the transaction-specified outputs.

There are several advantages to this separation of state generation and validation:

  • Deterministic transactions: Certainty of transaction execution is one of the core pursuits of decentralized applications. If transactions include only user input and new states are the result of computation on nodes (as seen in Ethereum), the transaction creator cannot be certain about the on-chain computation context, which may lead to unexpected results. In CKB, users generate new states on the client side. They can confirm the new states before broadcasting their state transition to the network. The transaction outcome is certain: either the transaction passes on-chain verification and the new state is accepted, or the transaction is deemed invalid and no state change is made to CKB (Figure 1).

  • 确定的交易(Deterministic transaction):交易(事务)执行的确定性是去中心化应用的其中一个核心要求。如果交易只包含用户输入,而且新的状态是节点上的运算结果(如我们在以太坊上面看到的),交易创造者并不能确定链上的计算内容,这可能会导致易想不到的结果。在CKB中,使用者生成新状态在客户端。他们可以在广播交易到全网前确认状态。无论交易是否能够通过验证,并且让新状态被接受,还是被认定是无效的交易并且没有新状态在CKB上,交易的结果都是确定的。

  • Parallelism: If transactions only include user inputs and new states are generated by nodes, then nodes will not know what state is going to be accessed by the verification process, and cannot determine dependencies between transactions. In CKB, because transactions explicitly include previous states and new states, nodes can see dependencies between transactions prior to verification, and can process transactions in parallel.

  • 平行处理(Parallelism):如果交易只包含用户输入而新状态只被节点所产生,那么节点不会知道什么状态将被验证的进程所接受,并且不能决定交易的依存(顺序)关系。在CKB中,因为交易明确的包含先前的状态和新状态,节点可以在验证前看到交易间的依存关系,并且可以平行的处理交易。

  • Higher resource utilization: As application logic is split and run in different places, the network can distribute computational workload more evenly across nodes and clients, and thus utilize system resources more efficiently.

  • 高度的资源使用:当应用程序的逻辑被分离并且在不同地方运行时,网络可以在节点和客户端之间更加公平的分配运算资源的工作量,并因此更加效率的使用系统资源。

  • Flexible state generation: Even when the same algorithms are used, developers can implement generation and validation in different ways. On the client side there is the flexibility to choose the programming language that provides for better performance and fast development.

  • 弹性的状态生成:即使当使用相同的算法,开发者可以用不同的方式来实现生成和验证。在客户端那边是可以弹性的选择提供更高性能以及更快速开发的程序语言。

In some scenarios, state verification can utilize a different (but associated) algorithm that is much more efficient than the one used for state generation. The most typical example is seen in Bitcoin transactions: Bitcoin transaction construction consists mainly of a searching process to identify appropriate UTXOs to use, while verification is the addition of numbers and simple comparison. Other interesting examples include sorting and searching algorithms: the computational complexity for quicksort, one of the best sorting algorithms for the average case, is O(Nlog(N)), but the algorithm to verify the result is just O(N). Searching for the index of an element in a sorted array is O(log(N)) with binary search, but its verification only takes O(1). The more complex the business rules, the higher probability that there can be asymmetric generation and validation algorithms with differing computational complexity.

System throughput can be improved by utlizing asymmetry between state generation and validation. Moving details of computation to the client side is also valuable for algorithm protection and privacy. With the advancement of technologies such as zero-knowledge proofs, we may find efficient generation and verification solutions to general problems, and CKB is a natural fit for these types of solutions.

We refer to programs that generate new states and create new cells as Generators. Generators run locally on the client side (off-chain). They utilize user input and existing cells as program inputs, to create new cells with new states as outputs. The inputs that Generators use and the outputs they produce together form a transaction.

Figure 2. Separation of state generation and verification

4.2 Cell

Cells are the primary state units in CKB, within them users can include arbitrary states. A cell has the following fields:

  • capacity – Size limit of the cell. A cell’s size is the total number of bytes of all fields contained in it.
  • data – State data stored in this cell. It could be empty, however the total bytes used by a cell (including data), must always be less than or equal to its capacity.
  • type: State verification script.
  • lock: Script that represents the ownership of the cell. Owners of cells can transfer cells to others.


  • 容量(capacity):细胞的大小限制。一个Cell的大小是包含所有字段的总字节数
  • 资料(data):状态数据储存在cell当中。他可以是空的,但是被Cell所使用的总字结数必须总是小于等于cell的容量
  • 型态(type): 状态验证的脚本
  • 上锁(lock): 一个代表cell的所有权的脚本。

A cell is an immutable object, no one can modify it after creation. Every cell can only be used once, it cannot be used as input for two different transactions. Cell ‘updates’ mark previous cells as history and create new cells with the same capacity to replace them. By constructing and sending transactions, users provide new cells with new states in them and invalidate previous cells that store old states atomically. The set of all current (or live) cells represents the latest version of all common knowledge in CKB, and the set of history (or dead) cells represents all historical versions of common knowledge.

CKB allows users to transfer a cell’s capacity all at once, or transfer only a fraction of a cell’s capacity, which would in turn lead to more cells being created (e.g., a cell with capacity=10 can become two cells with capacity=5).

Two kinds of scripts (type and lock) are executed in CKB VM. CKB VM executes the type script when a cell is created in a transaction output, to guarantee the state in the cell is valid under specific rules. CKB VM executes the lock script, taking proofs as arguments, when the cell is referenced by a transaction input, to make sure the user has appropriate permissions to update or transfer the cell. If the execution of the lock script returns true, the user is allowed to transfer the cell or update its data according to validation rules that are specified by the type script.

This type and lock script pair allows all kinds of possibilities, for example:

  • Upgradable cryptography – Anyone can deploy useful cryptography libraries written in languages such as C or C++ and use them in type and lock scripts. In CKB VM, there are no hardcoded cryptographic primitives, users are free to choose any cryptographic signature scheme they’d like to use to sign transactions.
  • Multisig – Users can easily create M-of-N multisig or more complex lock scripts.
  • Lending – Cell owners can lend cells for others to use while still maintaining their ownership of the cells.


  • 升级的加密算法(Upgradable cryptography)-任何人可以部署以C或C++语言写成的有用的加密函式库,并且在type和lock脚本中使用他们。在CKB的虚拟机中,这里没有写死( hardcoded)的加密基本体(cryptographic primitives),使用者可以自由的选择任何一种他们想用来签署交易的加密签名方式。
  • 多重签名(Multisig)使用者可以轻易地创造出N个M的多重签名或者更复杂的lock脚本
  • 借贷:cell的拥有者可以借出cells给其他人使用并同时维持cells的所有权。


4.3 VM 虚拟机

CKB的虚拟机是一个为了用来执行type和lock脚本,且基于RISC-V指令集的虚拟机。他只使用标准的RISC-V 指令集,以维护一个符合RISC-V标准的软件实现,他也能够涵盖最宽广的业界支持。CKB履行了加密基本体以作为运行在虚拟机上的普通程序集(assembly) ,而不是自定义的指令。他支持系统调用,也就是脚本可以读取如CKB上的近期交易或者一般的区块链信息等元数据(metadata)。CKB虚拟机定义了每条指令的循环,并且提供了执行在交易验证以帮助矿工决定交易手续费的总循环。

既有的区块链将加密基本体写死在协议当中。例如,比特币有特殊的加密操作码(opcodes)例如 OP_CHECK*,而以太坊则是使用特殊的「预编译」(precompiled)合约存放在一个特殊地址中(例如0000000000000000000000000000000000000001)来支持如ecrecover这种加密操作。为了添加新的加密基本体到这些区块链中,我们只能够过软分叉(例如比特币重新使用opcodes来支持新的基本體)或者硬分叉。

CKB虚拟机是一个与加密无关(crypto-agnostic )的虚拟机。没有任何关于密码学的特殊配置写死在CKB的虚拟机中。新的加密基本体总是能够被脚本部署和使用,就像一个普通的函示库。作为一个符合RISC-V标准的实现,代表以C语言写成的既存加密函式库,或者其他语言可以轻易的被转移到CKB的虚拟机上,并且被cell脚本所使用。CKB甚至可以实现交易验证中的默认哈希函数以及公私钥加密法。作为crypto-agnostic,允许去中心化应用开发者在Nervos上使用任何新的密码学技术(例如 Schnorr signatures, BLS signatures, and zkSNARKs/zkSTARKs),这将不影响其他使用者,并且让CKB使用者即使在一个后量子时代确保他们的资产安全。

CKB虚拟机选择一个硬件为目标的ISA,因为区块链是个如硬件般的软件。虽然他的创建像硬件一样容易,但更新却像硬件一样麻烦。作为一个为芯片所设计的ISA, RISC-V非常的稳定,他的核心指令集在未来是不会变的。能够在不需要硬叉的情况下保持与生态系统的兼容性是像CKB VM这样的区块链虚拟机的一个关键特性。RISC-V的简单性也使得运行时间成本的建模便容易,这对于计算交易费用而言相当重要。
如果想知道更多CKB VM的細節請參閱RFC 0003 。

4.4 Transaction 交易



  • deps:依赖Cell集合(Dependent cell set),提供了验证交易所需的只读cell
  • inputs:Cell的引用( references)和证明。Cell引用针对了激活在交易中被转移或者更新的cell。证明(例如签名)则用来证明交易的创造者已经允许去转移或更新被引用的cell。
  • outputs:新的cells在这个状态转换的情况下被创造

CKB的cell模型设计和交易设计对于轻客户端( light clients)而言是非常友善的。因为全部的状态都在区块中,区块的同步性也可以完成状态的同步性。轻客户端只需要同步区块而不需要额外的状态同步或状态转换计算。如果只有事件储存在区块中,全节点将会需要状态同步。跨大型网络的状态同步可能会非常困难,因为同步的诱因太过微弱。这和区块同步非常不同,区块同步指的是矿工尽可能的到处广播区块会得到奖励。在不需要额外的状态同步下,协议就可以让轻节点和全节点更加对等,从而建立一个更健壮和更去中心化的系统。

Figure 3. Transaction Parallelism and Conflict Detection
The deps and inputs in CKB transactions make it easier for nodes to determine transaction dependencies and perform parallel transaction processing (Figure 4). Different types of cells can be mixed and included in a single transaction to achieve atomic operation across types.

5. Economic Model 经济模型


5.1 State Cost and Cell Capacity 状态成本与Cell容量



Cell的元数据(capacity, type and lock)是状态,也就是会占据用户的Cell容量,并同时引发状态成本。这些元数据成本会激励用户尽可能地来减少Cells的使用,并增加储存效率。

5.2 Computation Cost and Transaction Fees 计算成本和交易费用





6. Network 网络


  • 挖矿节点:他们参与CKB共识过程。挖矿节点收集新的交易,封包他们到区块中并且在他们找到工作量证明的时候制造新的区块。挖矿节点并不需要储存全部的交易历史,而只须要储存最近的cell集合。

  • 全节点:他们需要验证新区块和交易,依据区块和交易,以及选择他们同意的链上分叉。全节点是网络中的验证者。

  • 轻节点:他们信任全节点,只有订阅和储存和他们相关的cells的子集。它们使用最小的资源。用户渐渐地依赖行动装置和手机Apps来进入互联网,轻节点就是为移动装置所设计。


7. Summary 结论


8. References 学术引用

Satoshi Nakamoto, “Bitcoin A Peer-to-Peer Electronic Cash System”, 2008
Vitalik Buterin, “Ethereum A Next-Generation Smart Contract and Decentralized Application Platform”, 2014

9. Appendix




- The Use of Knowledge in Society, Friedrich A. Hayek, 1945





謝謝Stwith! !


1 Like



1 Like

太棒了 我相信常常自己翻到最後會有盲點