共识算法追求在网络延迟和各类节点故障存在的情况下实现两个目标：正确性和性能。正确性又包括一致性（指分布式系统中每一个节点的数据副本完全相同）以及可用性（指分布式系统能够在有限的时间内响应用户的请求）。性能也包括两个方面，一是交易延迟（即从客户端提交Transaction到客户端获得确定性结果所需要的时间，越短越好）；二是吞吐量（即系统每秒中可以处理多少笔交易）。公有链运行在开放的分布式网络中，节点可以自由的加入和退出，在线节点不固定且变更频繁，这些都是传统BFT共识算法很难处理的问题。中本聪（Satoshi Nakamoto）巧妙的引入经济激励以及概率性共识应对这些难点，因此要保证正确性需要额外的开放性与公平性。开放性使共识节点的加入退出无阻碍，无论是有100000个节点还是1个节点，公有链都能正常工作；公平性使共识节点可以获得与所付出的努力成比例的回报。公有链共识算法的性能指标除延迟和吞吐量外，还需要考虑运行开销。以比特币工作量证明（Proof of Work）为代表的Nakamoto共识拥有极佳的开放性和可用性，比特币网络中的节点可以任意的加入和退出，网络性能随着共识节点数量的增加能够保持不变。但Nakamoto共识吞吐量低，以比特币7笔交易每秒的处理速度，难以消化商业场景的日常需求。即使通过次级通道技术（例如闪电网络）将?部分交易转移到链下，通道的建?与关闭依然受到链上处理速度的制约，在网络拥堵时甚至会影响到次级通道的安全性。Nakamoto共识以区块投票，交易确认速度慢，通常需要10分钟到一个小时，用户体验不佳。在分区的情况下，比特币网络能够继续提供服务，但交易是否被完全确认无法保证，无法满足对交易确定性要求较?的商业场景。经历了30年发展的传统拜占庭容错（Byzantine Fault Tolerance）共识可以实现媲美中心化系统的吞吐量和交易确认速度，但其开放性不佳，节点动态增减难度?，网络性能随参与共识的节点数量增加而迅速下降。传统BFT共识对故障的容忍能力较低，在网络分区时节点无法达成一致，网络无法正常提供服务，难以满足公有链对可用性的要求。比特币是世界上第一个区块链网络，专门为记录现?账本设计。比特币账本是比特币区块链网络维护的系统状态，账本中的最小存储单位是UTXO（未花费的交易输出）。用户可以使用钱包花费现有的UTXO，生成新的UTXO，并将其打包成交易，发送到比特币网络中接受验证和共识。UTXO中记录了?额以及表达所有权的锁脚本，用户必须提供相应的解锁数据才能够花费UTXO。由于UTXO数据结构以及比特币脚本能力的限制，我们很难使用比特币账本来记录其他类型的资产和数据，只能通过Color-coin、Meta-coin甚至硬分叉这样的方案来满足不同的场景，实现应用的代价很?。以太坊通过智能合约引入通用性计算，创造出了一个基于智能合约实现的生态。以太坊账本是以太坊区块链网络维护的系统状态，账本由账户构成，账户内部可以存放代码，并提供一个256bits KV数据库存放数据，这样存放了代码的账户就是以太坊智能合约。用户在以太坊上可以发出两种类型的交易：一种交易可以创建合约，将用户编写的应用逻辑部署到区块链上，存放到合约账户中；另一种交易可以将用户提供的输入数据发给指定的合约账户，触发账户所保存的代码的执行，由代码产生更新账户内的KV数据库，产生新的内部状态。以太坊智能合约提供了更强?的计算能力以及灵活性，在一定程度上解决了比特币的问题，但依然有其局限性：：以太坊以状态机事件作为设计中心（图1），交易中包含的是状态机事件输入，而不是状态本身，再加上EVM的图灵完备性，节点在处理交易之前难以判断交易相关性，难以对交易进行并行处理。同时，由于交易中没有包含账本状态，分片时还需要额外解决数据可用性难题。：合约状态由合约代码更新，而合约代码执行又受执行环境影响（例如被调用合约的当前状态）。因此用户在发起交易时无法完全确定交易执行后的结果。：以太坊智能合约将计算和存储紧紧绑定，形成一个不可更改的整体。用户必须使用账户模型、EVM字节码以及256bits KV数据库范式来实现所有场景，缺乏效率和灵活性。现有区块链的经济模型也面临着越来越多的挑战。随着用户和应用的增多，区块链上存储的数据也越来越多。现有的经济模型只考虑计算成本，使得用户产生的数据可以无成本的占用所有节点的存储空间。网络中使用的代币价格波动性极?，在代币价格上涨时为应用使用者制造了难以承受的?续费负担。

综上，我们重新思考并设计了Nervos CKB，提出彻底解耦的分布式应用新范式，以?持更普遍的计算和存储需求，获得更好的性能，使经济激励更平衡，对移动设备更友好。我们希望Nervos CKB可以成为全球76亿?的共同知识库，承载各种分布式应用。

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），容易组合形成更复杂的逻辑。

Nervos网络可以使用相同的算法进行状态生成和验证。在这个模型中，客户端使用该算法生成新的状态，节点利用交易中记录的依赖状态作为输入，执行同样的算法，对比输出的状态是否与交易中记录的新状态相同，相同则验证通过。在使用相同算法的情况下，状态生成和验证只有执行环境的差别，没有计算复杂度的差别。将生成和验证分离，生成转移到客户端执行的好处是：：交易的确定性是分布式应用的核心诉求之一。交易时延的确定性（Hybrid Consensus）已经得到了?泛的重视，但交易结果（即由交易产生的新状态）的确定性却往往被忽视。如果状态在节点生成，用户在发起状态生成请求时无法完全确定请求被执行时的环境，由此可能产生用户不希望的执行结果。在CKB中，由于新的状态由用户生成，由用户完全确定新状态之后再?播，交易所能触发的状态变更用户可以完全确定。要么交易通过验证，由用户生成并确认的新状态被接受，要么交易没有通过验证，不造成任何状态改变（图2）。：如果状态在节点生成，节点在处理交易前无法判断该交易依赖哪些状态，也就无法判断交易的相关性。在CKB中，由于交易显式地包含了交易依赖的旧状态以及生成的新状态，节点可以直接判断交易之间的相关性（Transaction）。无相关性的交易可以通过各种方式并行处理，包括多核并行及分片。并行处理交易是解决区块链性能扩展问题的关键。：充分利用客户端计算资源，减轻节点计算负担，整体效率更?。：虽然使用相同的算法，但是生成和验证可以使用不同的方法实现。客户端可以灵活选择合适的编程语?来实现生成算法，计算效率可以更?，生成程序可以无缝集成到运行平台中，提供最好的用户体验。对于许多特定类型的场景，我们可以找到计算复杂度远低于生成算法的验证算法，最典型的例?是UTXO账本和非对称签名。还有其他涉及排序和搜索的算法：平均复杂度最好的排序算法QuickSort的计算复杂度是 O(NlogN) ，而验算排序的复杂度总是只有 O(N) ；如果要搜索一个元素在数组中的位置，在数组已经排好序的情况下计算复杂度为 O(logN) ，而验算的复杂度是 O(1) 。对于越复杂的场景，出现生成与验算复杂度不对称情况的概率更?。在可以利用这种不对称性的情况下，节点处理效率会有极?的提升，更多的计算细节只存在于客户端，也更有利于算法保护和隐私保护。随着密码学技术的发展，我们可能会发现为通用问题设计非对称生成和验证算法的方法，例如通用的非交互式零知识证明。CKB的状态生成与验证分离架构也能够为其提供恰到好处的?持。

下?将对CKB的Cell数据模型及交易数据结构作示意性的描述，目的是更好的友们CKB的功能。在CKB的具体实现中，需要考虑包括激励一致、执行效率在内的其它因素，数据结构会更为复杂，相关细节将在专门的技术?档中描述。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，使用门槛低。

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

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

Generator是生成程序，用来生成符合类型定义的新的Cells。Generator在发起交易的客户端本地执行，以用户的输入以及现有的Cells作为输入，生成包含新状态的Cells作为输出。Generator用到的输入以及产生的输出共同构成一个Transaction（图5）。通过定义Data Schema, Validator和Generator，我们可以在CKB中实现任意共同知识的验证和存储。例如，我们可以定义一个 AlpacaCoin 的新类型：Data Schema={amount “uint”}pseudo code of checker check()1. 检查inputs列表中的项都有正确的解锁数据2. 计算inputs列表中AlpacaCoin的amount之和IN3. 计算outputs列表中的AlpacaCoin的amount之和OUT4. 比较IN和OUT是否相等，并返回结果Validator=validate(context ctx, inputs, outputs)pseudo code of generator gen()1. 查找用户能够花费的，属于AlpacaCoin类型的Cells2. 根据用户输入的转账地址和?额，生成类型为AlpacaCoin的属于收款?的Cell和找零Cell3. 返回被使用的Cells列表，以及新生成的Cells列表，这些Cells将用于构造交易Generator=gen(context ctx, address to, uint amount, …)