比特币是世界上第一个区块链网络，专门为记录现金账本设计。比特币账本是比特币区块链网络维护的系统状态，账本中的最小存储单位是 UTXO（未花费的交易输出）。用户可以使用钱包花费现有的 UTXO，生成新的 UTXO，并将其打包成交易，发送到比特币网络中接受验证和共识。UTXO 中记录了金额以及表达所有权的锁脚本，用户必须提供相应的解锁数据才能够花费UTXO。由于 UTXO 数据结构以及比特币脚本能力的限制，我们很难使用比特币账本来记录其他类型的资产和数据，只能通过 Color-coin、Meta-coin 甚至硬分叉这样的方案来满足不同的场景，实现应用的代价很高。

Nervos CKB（以下简称 CKB）是一个以通用共同知识库（Appendix: Common KnowledgeBase）为设计目标的区块链。CKB 网络由存档节点、共识节点和轻节点组成：

• 存档节点：CKB 全节点，对新的区块和交易进行验证，中继传播区块和交易，保存 CKB上所有的交易历史。存档节点能提高整个网络的健壮性，为 CKB 上的应用提供历史查询。• 共识节点：参与共识协议的 CKB 节点。共识节点接收新的交易，将交易打包成块，并对新生成的区块产生共识。共识节点不需要保存所有的交易历史。• 轻节点：用户通过轻节点使用 CKB 网络，轻节点只保存非常少量的数据，可以运行在桌面电脑或者是移动设备上。

CKB 节点通过点对点网络协议组成一个分布式网络，对区块和交易数据进行转发和广播。共识节点运行混合共识协议，以一定的时间间隔产生新的区块并形成共识，新区块会被所有节点承认并追加到区块链尾部，新区块中的交易会更新 CKB 的状态。

一个新的DApp范式

CKB 提出一种全新的分布式应用范式，该范式由以下五种元素组成：

• Cell• Type• Validator• Generator• Identity

通过这五种元素，我们将分布式应用彻底解耦成计算、存储和身份三个方面。在此基础上，计算进一步分化为生成（Generator）和验证（Validator）两个步骤，存储（Cell）也进一步通用化，可以支持任意结构化（Type）的数据。CKB 中的分布式应用，可以使用 Type 定义合适的数据结构，将应用数据存放在多个 Cells 中；应用的执行逻辑由 Generator 实现，状态验证逻辑由 Validator 实现；Generator 在客户端运行，用户进行操作时生成新的应用状态，新状态被打包在交易中发送到全网；网络中的节点先验证交易发送者的身份，然后使用 Validator 对交易中新状态的有效性进行验证，验证通过后将新状态保存到 CKB 中。

CKB 以状态为核心设计数据流及经济激励，交易中包含的是新的状态，而不是触发状态机的事件。因此，CKB 区块链中直接保存了状态数据，状态随着区块一起同步，无需额外的状态同步协议，降低了系统复杂度，提高了系统可用性。分布式应用的状态被剥离到 Cells 中保存，Validator 和 Generator 内部没有任何状态，计算结果完全依赖输入，因此都是确定性的纯函数（Pure function），容易组合形成更复杂的逻辑。CKB 分布式应用使用的是一种近似Lambda Calculus 的计算范式，能够实现与图灵机相同的计算能力。

表 1 将 Bitcoin、Ethereum 和 Nervos CKB 进行了比较。

状态生成和验证

在 CKB 中状态生成和验证分离，两个阶段可以既可以使用不同的算法，也可以使用相同的算法。对于一般的场景，目前还没有通用且高效的简化验证算法的方法。在这种情况下，我们使用相同的算法进行状态生成和验证：客户端使用该算法生成新的状态，节点利用交易中记录的依赖状态作为输入，执行同样的算法，对比输出的状态是否与交易中记录的新状态相同，相同则验证通过。在使用相同算法的情况下，状态生成和验证只有执行环境的差别，没有计算复杂度的差别。将生成和验证分离，生成转移到客户端执行的好处是：

• 确定性：交易的确定性是分布式应用的核心诉求之一。交易时延的确定性（Hybrid Consensus）已经得到了广泛的重视，但交易结果（即由交易产生的新状态）的确定性却往往被忽视。如果状态在节点生成，用户在发起状态生成请求时无法完全确定请求被执行时的环境，由此可能产生用户不希望的执行结果。在 CKB 中，由于新的状态由用户生成，由用户完全确定新状态之后再广播，交易所能触发的状态变更用户可以完全确定。要么交易通过验证，由用户生成并确认的新状态被接受，要么交易没有通过验证，不造成任何状态改变（图 2）。

• 可并行性：如果状态在节点生成，节点在处理交易前无法判断该交易依赖哪些状态，也就无法判断交易的相关性。在 CKB 中，由于交易显式地包含了交易依赖的旧状态以及生成的新状态，节点可以直接判断交易之间的相关性（Transaction）。无相关性的交易可以通过各种方式并行处理，包括多核并行及分片。并行处理交易是解决区块链性能扩展问题的关键。

• 计算分布式程度高：充分利用客户端计算资源，减轻节点计算负担，整体效率更高。

• 客户端更灵活，容易与客户端所在平台集成：虽然使用相同的算法，但是生成和验证可以使用不同的方法实现。客户端可以灵活选择合适的编程语言来实现生成算法，计算效率可以更高，生成程序可以无缝集成到运行平台中，提供最好的用户体验。

对于许多特定类型的场景，我们可以找到计算复杂度远低于生成算法的验证算法，最典型的例子是UTXO 账本和非对称签名。一个很有趣的例子是涉及排序和搜索的算法：平均复杂度最好的排序算法 QuickSort 的计算复杂度是 O(NlogN)，而验算排序的复杂度总是只有 O(N)；如果要搜索一个元素在数组中的位置，在数组已经排好序的情况下计算复杂度为 O(logN)，而验算的复杂度是 O(1)。对于越复杂的场景，出现生成与验算复杂度不对称情况的概率更高。

下文将对 CKB 的 Cell 数据模型及交易数据结构作示意性的描述，目的是更好的解释 CKB 的功能。在 CKB 的具体实现中，需要考虑包括激励一致、执行效率在内的其它因素，数据结构会更为复杂，相关细节将在专门的技术文档中描述。

Cell

CKB 中数据的可信度来源有两种，一种是数据可以客观验证，一种是数据经过特定身份用户的背书。因此，CKB 中数据的最小单元必须包含以下要素：

• 数据本身• 数据的验证方法• 数据提交者的身份

Cell 是 CKB 中的最小数据单元，可以存放任意的数据。Cell 包含以下基本内容：

• type: Cell 的数据类型。• capacity: Cell 容量，可存放数据的最大字节数。• data: Cell 实际存储的二进制数据，可以为空。包含 data 在内，cell 占用的字节数总是小于等于 capacity。• owner_lock: 通过脚本表示的 Cell 所有者。Cell 所有者可以转让 Cell。• data_lock: 通过脚本表示的 Cell 使用者。Cell 使用者可以更新 data。

Cell 一旦创建无法更改，是一种不可更改（immutable）的数据单元。对 Cell 的更新，实质上是通过创建所有权相同的新 Cell 来实现。用户通过交易提交包含新数据的新 Cell，同时使老的 Cell 失效（见Life Cycle）。因此，CKB 也可以看作是一个支持版本的数据仓库，最新的Cells 代表了数据仓库的当前版本，已经失效的 Cells 代表了数据仓库的历史。

对 Cell 的操作权分为两种，所有权和使用权。Cell 的 owner_lock 规定了所有权，即转让Cell capacity 的权利；Cell 的 data_lock 规定了使用权，即创建新的 Cell 来更新 Cell 内容的权利。Cell capacity 可以一次全部转让，也可以部分转让，部分转让会创建新的 Cell（比如一个 capacity 为 10 的 cell 变成两个 capacity 各为 5 的 cell）。Cell capacity 的增长速度由共识参与度及流动投票决定。

Cell 的 lock 脚本由 CKB 支持的虚拟机执行，用户在更新 Cell 数据或是转让 Cell 时需要提供相应的证明作为 lock 脚本输入，如果 lock 脚本执行结果为 True 则证明用户具有相应的权限，可以进行操作。

lock 脚本表达了 Cell 的操作权限，可以代表单用户，也可以是门限签名或者更复杂的权限。Cell 具有很好的隐私性，用户通过使用不同的 lock 脚本，可以很轻松地使用不同的假名（Pseudonomy）来管理自己的 Cells。Cell 的所有者和使用者可以是相同的用户，也可以是不同的用户，这也意味着 CKB 使用者不需要拥有 Cell 就可以使用 CKB，使用门槛低。

生命周期Cell 生命周期有两个阶段，新创建的 Cell 处于第一个阶段 P1。Cell 是不可变数据对象，一旦被创建其内容不能被修改，Cell 的更新通过 Transaction 实现：Transaction 以需要被更新的 P1 Cell 作为输入，以 Generator 产生的包含新状态的 P1 Cell 作为输出。

一个 P1 Cell 只能被使用一次，不能被用作两个不同 Transaction 的输入。P1 Cell 被使用后进入第二个阶段 P2，P2 Cell 不能再用作 Transaction 输入。我们把所有的 P1 Cells 形成的集合称为 P1 Cell Set（P1CS），P1CS 中存储了 CKB 当前所有的共同知识；所有的P2 Cells 形成的集合称为 P2 Cell Set（P2CS），P2CS 中存储了 CKB 所有的历史状态。

CKB 网络上的全节点只需要 P1CS 就可以验证 Transaction，P2CS 可以按照一定的策略清理。P2CS 可以保存在存档节点（Archive Node）或者是分布式存储网络上。CKB 轻节点只需要保存区块头和特定的 Cells，不需要保存完整的 P1CS 和 P2CS。

类型

CKB 为 Cell 提供了类型系统，用户可以创建自定义的 Cell 类型。通过类型系统，我们可以在CKB 中定义不同结构的共同知识以及相应的生成验证规则。

创建新的 Cell 类型需要定义 Data Schema 和 Validator 两个要素：

• Data Schema: 定义新类型的数据结构。• Validator: 定义新类型的验证程序。

Data Schema 和 Validator 的定义也是一种共同知识，存放在 Cell 中。每一个 Cell 都有一个且仅仅一个类型，多个 Cell 可以属于同一个类型，也可以属于不同的类型。

Data Schema 提供该类型的数据结构定义，使 Validator 可以理解和使用 Cell 中保存的数据。Validator 为验证程序，由每一个节点使用 CKB 支持的虚拟机执行，以交易的 Deps,Inputs 和 Outputs 作为程序输入（Transaction），能够通过验证就返回 True，不能则返回False。Cell 的创建、更新和销毁可以使用不同的验证规则。

指数

用户在定义 Data Schema 时可以设置索引，添加了索引的数据字段能够获得额外的支持，包括能够在 Validator 或是 owner_lock/data_lock 中使用的条件查询指令以及聚合函数。例如，众筹发起方可以生成一个 Identity Cell（Identity），在其 data_lock 中利用条件查询和聚合函数判断属于这个 identity 的代币总数是否已经达到众筹目标，实现有上限的众筹。

Identity

Identity 是一种系统类型，用户可以任意创建属于自己的 Identity Cell。Identity Cell 可以作为 Cell data_lock/owner_lock 使用，Cell 更新或者转让时，需要提供对应 IdentityCell data_lock 的解锁脚本（图 3）。

Identity 是广义的身份，Identity 可以对应个人或者机器实体的任何身份侧面。Identity 是Nervos 网络中分布式身份协议 NIP（详见 Nervos Identity Protocol Paper）的基础。通过 NIP，Nervos 网络引入 CA 证书，可以兼容现有的 PKI 体系，用户可以表达自己的社会身份，分布式应用可以基于身份构建。Identity Cell 中可以存放公开身份信息，或者是身份信息摘要，由用户在必要时与分布式应用交互，提供所需的详细信息。

相对于 UTXO 或是账户，Cell 是一种更加通用的存储模型。UTXO 模型和账户模型都可以表达资产和所有者之间的关系：UTXO 以资产为基础定义所有权（锁脚本），账户则以所有者为基础记录资产（账户余额）。UTXO 模型中的帐目变动更清晰，但显式账户概念的缺乏使表达能力本就欠缺的脚本更加难以使用，也无法记录权限等账户元信息。账户模型容易理解，可以很好的支持身份和权限系统，却有交易难并发的问题。支持类型和 Identity 的 Cell 设计集成了这两种模型的优点，创造了一种更加通用的数据模型。

Transaction

Transaction 表达了 Cells 的转让和更新。在一个 Transaction 里面用户可以转让 Cell，或是更新一个或者多个 Cell 的内容。Transaction 包括以下基本内容：

• deps: 依赖集合，对交易进行验证所依赖的只读数据，只能是 P1 Cells 的引用或者用户输入。• inputs: 输入集合，包含需要被转让/更新的 Cells，只能是 P1 Cells 的引用及相应的解锁脚本。• outputs: 输出集合，包含新产生的 P1 Cells。

由于 Cell 的不可变更性，更新 Cell 时不会直接修改旧的 Cell，而是会产生一个新版本的 Cell，这些 Cell 版本可以前后衔接在一起，形成 Cell 的 “版本链”：某一次 Cell capacity 转让时创建了这个 Cell 的第一个版本，对 Cell 的后续更新形成了这个 Cell 的一系列历史版本，在版本链的最后 (Head) 是 Cell 的最新版本。CKB 是所有 Cell 版本链的集合，所有 Cell Heads的集合是 CKB 的当前版本。

CKB Transaction 中包含的 deps 和 inputs 使节点可以方便地判断交易间的依赖关系，对交易进行并行验证（图 4）。Transaction 中可以混合多种类型的 Cell，可以方便的实现跨类型的原子性操作。

CKB Cell 模型和 Transaction 的设计使 CKB 对轻节点更友好。由于所有的状态都在区块中，区块同步协议也支持了状态同步。轻节点只需要同步区块，不需要计算（生成状态），就可以获得新的状态。如果区块中只保存事件，则需要全节点支持额外的状态同步机制。在缺乏激励的情况下，区块链协议之外的额外机制很难大范围的部署。在区块链协议内同步状态，使轻节点与全节点之间的地位更平等，系统更加健壮和去中心化。

Generator

Generator 是生成程序，用来生成符合类型定义的新的 Cells。Generator 在发起交易的客户端本地执行，以用户的输入以及现有的 Cells 作为输入，生成包含新状态的 Cells 作为输出。Generator 用到的输入以及产生的输出共同构成一个 Transaction（图 5）。Validator 和 Generator 可以使用相同的算法，也可以使用不同的算法（Overview）。Generator 可以接受一个或者多个相同或者不同类型的 Cell 引用作为输入，可以产生一个或者多个相同或者不同类型的新 Cells 作为输出。

通过定义 Data Schema, Validator 和 Generator，我们可以在 CKB 中实现任意共同知识的验证和存储。例如，我们可以定义一个 AlpacaCoin 的新类型：

Data Schema = {amount: “uint”}

// pseudo code of checker check():// 1. 检查 inputs 列表中的项都有正确的解锁数据// 2. 计算 inputs 列表中 AlpacaCoin 的 amount 之和 IN// 3. 计算 outputs 列表中的 AlpacaCoin 的 amount 之和 OUT// 4. 比较 IN 和 OUT 是否相等，并返回结果

Validator = validate(context ctx, inputs, outputs)

// pseudo code of generator gen():// 1. 查找用户能够花费的，属于 AlpacaCoin 类型的 Cells// 2. 根据用户输入的转账地址和金额，生成类型为 AlpacaCoin 的属于收款人的 Cell 和找零 Cell// 3. 返回被使用的 Cells 列表，以及新生成的 Cells 列表，这些 Cells 将用于构造交易

Generator = gen(context ctx, address to, uint amount, ...)

Figure 5. Transaction and Cell Generation/Validation

Layered Network

在 Nervos 网络中，CKB 和 Generator 构成上下层的关系，CKB 是共同知识层，而Generator 是生成层。CKB 只关心 Generator 产生的新状态，不关心状态产生的具体方式，因此 Generator 的具体实现形式是非常多样化的（图 6）。

分层架构将数据与计算分离，使每层都可以获得各自的灵活性与可扩展性，使用不同的共识协议。CKB 作为最底层，拥有最广泛的共识，是整个 Nervos 网络的基础。不同的应用所需要的共识范围不同，强制所有应用都在最广泛的共识下进行会导致效率低下。在 Nervos 网络中，业务参与方可以根据自己所需的共识范围选择合适的 Generator，只在需要与局部共识范围外的其他服务交互时，将局部状态提交到 CKB 上，使其获得更广泛的认同。

Generator 可以包括（但不限于）以下几种形式：

• 客户端在用户设备上直接运行 Generator 生成新状态。通过轻客户端提供的接口或是客户端程序库，生成算法可以用任何编程语言实现。

• 状态服务用户使用中心化服务，由服务器执行生成算法，生成新状态。目前所有的互联网服务都可以通过状态服务的方式使用 CKB，使服务状态数据获得更大的信任和流动性。例如，游戏公司可以使用状态服务架构，在中心化服务中执行游戏逻辑，生成道具信息；在 CKB 中定义道具类型和总量等规则，将生成的道具登记并确权。

结合 Nervos Identity Protocol，信息发布机构提供基于身份的可信 Oracle，为Nervos 网络中的其他服务提供必要的信息。

• 状态通道两名或多名用户使用点对点网络连接通信，共同生成新的状态。状态通道的参与者可以通过CKB 登记和获取参与者信息，建立通道连接。参与者可以在 CKB 上提供保证金，使其它参与者相信通道能够顺利运行。状态通道参与者之间可以使用共识协议或是多方安全计算技术来生成新状态。

• 生成链一个用于生成 CKB 新状态的区块链。生成链可以是公有链（例如任何使用 EVM 的区块链），也可以是许可链（例如 CITA 以及 Hyperledger Fabric）。使用许可链可以将状态计算限定在一定参与范围内，保护计算隐私，同时获得很好的性能。在应用链中，参与者共同执行状态生成并相互验证计算过程，在状态需要更广泛共识时，将其提交到 CKB中，使之成为接受度更高的共同知识。

Hybrid Consensus

共识算法追求在网络延迟和各类节点故障存在的情况下实现两个目标：正确性和性能。正确性又包括一致性，指分布式系统中每一个节点的数据副本完全相同，以及可用性，指分布式系统能够在有限的时间内响应用户的请求。性能也包括两个方面，一是交易延迟，即从客户端提交 Transaction到客户端获得确定性结果所需要的时间，越短越好；二是吞吐量，即系统每秒中可以处理多少笔交易。

公有链运行在开放的分布式网络中，节点可以自由的加入和退出，在线节点不固定且变更频繁，这些都是传统 BFT 共识算法很难处理的问题。Satoshi Nakamoto 巧妙的引入经济激励以及概率性共识应对这些难点 [2]，因此要保证正确性需要额外的开放性与公平性。开放性使共识节点的加入退出无阻碍，无论是有 100000 个节点还是 1 个节点，公有链都能正常工作；公平性使共识节点可以获得与所付出的努力成比例的回报。公有链共识算法的性能指标除延迟和吞吐量外，还需要考虑运行开销。

以比特币工作量证明（Proof of Work）为代表的 Nakamoto 共识拥有极佳的开放性和可用性，比特币网络中的节点可以任意的加入和退出，网络性能随着共识节点数量的增加能够保持不变。但 Nakamoto 共识吞吐量低，以比特币 7 笔交易每秒的处理速度，难以消化商业场景的日常需求。即使通过次级通道技术（例如闪电网络）将大部分交易转移到链下，通道的建立与关闭依然受到链上处理速度的制约，在网络拥堵时甚至会影响到次级通道的安全性。Nakamoto 共识以区块投票，交易确认速度慢，通常需要 10 分钟到一个小时，用户体验不佳。在分区的情况下，比特币网络能够继续提供服务，但交易是否被完全确认无法保证，无法满足对交易确定性要求较高的商业场景。

经历了 30 年发展的传统拜占庭容错（Byzantine Fault Tolerance）共识可以实现媲美中心化系统的吞吐量和交易确认速度，但其开放性不佳，节点动态增减难度大，网络性能随参与共识的节点数量增加而迅速下降。传统 BFT 共识对故障的容忍能力较低，在网络分区时节点无法达成一致，网络无法正常提供服务，难以满足公有链对可用性的要求。

在研究和实践中我们认识到，传统 BFT 算法在正常路径下逻辑简单，但需要以复杂的逻辑应对故障情况；Nakamoto 共识则以不变应万变，无论是正常还是故障情况都是同样的逻辑，但也因此影响了正常路径下的系统性能。如果将 Nakamoto 和传统拜占庭容错两类共识协议有机的结合在一起，新的混合共识在一致性、可用性、公平性及运行开销等方面可以形成最佳组合 。

CKB 将按照混合共识的思路，设计并实现自己的混合共识算法，为交易提供见证。通过将Nakamoto 共识和传统 BFT 共识结合，我们既可以保留开放性和可用性，又可以在正常路径下获得传统 BFT 共识的优秀性能，将交易时延降到最低，最大程度的提升系统吞吐量。

CKB 以 Cell Capacity 作为参与共识的条件。想要参与共识的节点需要抵押一定数量的 CellCapacity 作为保证金，用于确定共识节点的投票和奖励分配权重。如果某个共识节点作恶，观察到作恶行为的其它共识节点可以将证据提交到链上，导致作恶节点的保证金被系统罚没。保证金机制能增加共识节点作恶的成本，提高共识的安全性。CKB 混合共识的详细设计请参考 CKB Consensus Paper。

Economics

经济模型是公有链的灵魂。通过引入经济激励，比特币第一次解决了开放网络上的共识难题。每一个区块链网络都是一个通过经济激励结合在一起的自治共同体。一个优秀的经济激励制度应该引导区块链的参与者为这个自治共同体作出贡献，最大化区块链的效用。

CKB 经济模型应该能够激励用户、开发者和节点运行者合力为共同知识的形成与保存贡献力量。CKB 的经济模型同样以状态为核心进行设计，通过 Cell Capacity 增发和手续费两部分奖励产生激励。