从根本出发，探索区块链共识的四个阶段

在接下来的秘猿科技小课堂里，咱们会从技术角度、经济模型设计角度、以及共识角度来拆解 Nervos 加密经济网络中，底层公链 CKB 的设计理念。而本文将会做为技术角度核心设计 Cell 模型的预备文章，经过本文，咱们但愿读者可以理解比特币以状态为中心设计的优点！从而，可以在接下来的几篇文章中，更加充分的理解 Cell 模型对于比特币/以太坊模型的传承与突破。（PS.本文源于 2018 年初，秘猿科技在招商银行总行举办的一次金融区块链闭门会，公链 CKB 是对文中思想的具体实现。）

秘猿科技区块链小课堂第 16 期

---

如何对状态机建模

状态机是计算机的一个基本模型，它能够分红二个部分：状态和操做。状态是指计算机里的数据；操做是指对数据进行的操做。若是把状态机比喻成平常使用的数学计算器，计算器屏幕上显示的就是状态，按「按键」就是对计算器的操做。

状态机模型

区块链用许多的节点共同模拟了一台多复本的状态机。在许多区块链或者分布式系统中，用户发出的签名交易包含了对状态机的操做，节点执行共识协议对全部操做进行排序，而后按共识排好的顺序执行操做，计算出新的状态。

多复本状态机

举例：咱们先保证全部节点初始状态一致，就是让每人手上的计算器开始状态为数字 0。而后咱们把要执行的操做广播给每一个操做员，这四个操做员算完后，这个计算器上的最终结果是如出一辙的。为何会有同样的结果？由于他们有一个相同的初始状态。接着，咱们用共识算法保证了相同的操做顺序。因此最后必定有一个相同的最后状态。

状态机的概念在区块链里面很是重要，但咱们每每忽视其中的基本细节。设计区块链最应该考虑的因素，是应该以状态为中心，仍是以操做为中心进行设计？这二种不一样的设计理念会对总体架构产生很大影响，这也是比特币和以太坊架构的一个根本区别：比特币是以状态为中心的设计，以太坊是以事件为中心的设计。

这二者有很是大的区别。若是以事件为中心，计算是在节点上发生；以状态为中心的话，计算是在客户端发生。计算转移到客户端，节点的计算就相应减小。交易包含最后的状态的话，节点能够很方便的判断交易的相互依赖关系。计算在节点上发生的话，客户端就能够很简单。因此咱们须要根据目标来权衡这个事情。其实很难说谁更好，只是看咱们目标是什么。

如何设计帐本

区块链被称为分布式帐本，记录着全部者和资产之间的关系。帐本里有二个概念，一个是资产，一个是全部者。因此能够从二个方向去设计系统。

帐本设计

帐户模型以「人」为核心建模，先创建帐户的概念，再记录他们的帐户里有多少钱，以太坊、CITA 、Ripple 都是这个模型；以「资产」为核心建模，最基础的概念是资产，好比 UTXO，在 UTXO 的基础上去记录全部权。以资产为核心建模，更适合并行处理，一我的所拥有的资产再也不是一个字段，而是可能分红十份。我能够独立去操做这十份资产。

RSM设计

以帐户为核心的设计，交易并行处理更难，帐户更改只能按照交易顺序一个一个来。可是，帐户模型能够很方便的去记录帐户相关的元数据，好比说这个帐户有哪些权限。因此对于许可链来讲，帐户模型是很是适合的选择。

如何选择共识

在公有链上，比特币所开创的 Nakamoto 共识，在开放网络下，引入了经济激励，在开放网络下实现了对拜占庭错误的容忍，但也付出了性能上的代价。许可链中一般使用传统拜占庭共识的变种，充分利用了分布式系统领域过去几十年的研究成果。优势是延迟很是低、吞吐量很高。

在网络分裂时，许可链是选择网络中止服务，等待网络的恢复，来保证一致性；公有链则偏好可用性，在网络分裂时能够容忍帐本分红二个版本，等网络恢复以后，选择其中一个版本做为正确的版本，废弃掉另一个版本。公有链想要的是 24 小时不间断的服务；金融行业回滚的代价太大，想要的倒是一致性。因此选择 C 仍是选择 A，取决于你的需求是什么。

区块链共识的四个阶段

第一阶段是「加入共识」

加入共识阶段决定了什么样的节点能够参与共识协议。好比：在比特币中，一开始是任意节点均可以加入共识。如今则能够认为比特币的共识加入机制变成了买矿机，有矿机才能参与共识。在 PoS 里面，则是须要持有代币或者交保证金才能参与共识。在 DPoS 里面，代理人须要得到足够多的投票才能参与共识。学术界也有其余的研究，好比是加入共识也须要提供一个工做量证实。

经过加入共识阶段的设计，咱们能够把参与共识的节点范围缩小。好比公有链上有一万个节点，可是咱们只要设计一个加入共识的机制，就能够把共识范围缩小到 100 个节点，一旦咱们能够缩小这个共识范围，后面就能够用任意的方法去实现共识。

第二阶段是「出块」

这个阶段须要选择一个节点来将交易打包，生成一个新的区块。一般有三种方式：

1.共识节点按轮流顺序出块，好比 PoA。
2.采用随机出块方式，从 共识节点里随机挑一个节点出块，好比 PoW, NXT-PoS，DPoS。
3.在不出问题的状况下一直保持一个节点出块，目前只有许可链会用这种方式。

第三阶段是「进行验证和投票」

涉及到共识投票的过程，这里的设计就很是多。如今你们常常在讨论的一些新的共识方法，每每只是第二和第三阶段的方案。

投票主要有用区块投票和用消息投票两种方式。在 Nakamoto 共识中，新制造的区块是一张投票，下一个矿工挖出的块是对以前一系列区块的投票。每个区块都是一张票（严格来讲票有权重，例如工做量证实），最后那条高度最长，包含的区块（票数）最多，就是胜出的那条链。在许可链里面，经常经过节点之间交换投票消息来对新出的块进行投票，因此在下一个块没有出以前就能够对这一个块完成共识。

第四阶段是「退出共识」

这是经常被忽略的部分。在比特币系统中，退出共识很简单，中止挖矿就好了。在许可链中，咱们原本是共识节点，如今不想作共识节点了，则须要有相应的设计，进行共识节点变动。

以上四个步骤是区块链共识的一个完整流程。传统 BFT 共识算法，发挥做用通常是在第三阶段，在网络异步的时候会涉及第二阶段，基本上不讨论其它两个阶段。因此咱们若是要将传统的共识算法融入到区块链中，须要另外考虑的问题是很是多的。

将来咱们能作什么

在设计 CITA 的时候，咱们是为企业级的用户考虑的。他们拥有很好的计算资源，因此咱们能够经过内部并行和分片的方式解决区块链面临的性能扩展的问题，把区块链里每个节点的能力放大一百倍，那么整个网络的能力就会放大一百倍。这是咱们 CITA 提出微服务的起因。咱们把一个节点拆散，将节点内部变成一个集群是 CITA 可以提高吞吐量的根本缘由。在 CITA 里面有不少的微服务，好比 auth 服务是交易验证的，是能够并行处理的。因此咱们经过这个方式去解决性能瓶颈问题。

微服务

CITA 的设计目标是多中心的区块链网络。这样的网络不须要太多的节点，就能够创造很高的信任。这是咱们本身在某云平台上作的一个实测。用了一个中型的云服务器，通常交易处理能够达到 15000 TPS，测试用例包括存证，合约建立和代币转移， 都有比较好的性能。特别指出的，CITA 这种架构对云计算很友好。咱们更加倾向从架构的角度、从软件的角度解决各类问题。尽可能避免去依赖硬件。

性能对比

在咱们工程设计和实现中咱们会遇到不少选择，咱们每每是选了一边。有没有可能兼得呢？我认为在一些地方是能够的。好比以太坊上的智能合约很是的轻量，经过 evm 合约构造分布式应用时，能够生成成千上万的合约共同来完成一个使命。Fabric 上的合约能够用任意原生语言实现，执行环境比较重。CITA 则同时支持二种方式，既能够跑evm合约，又能够跑原生合约。

将来，咱们还能够作什么呢？好比如今的共识算法的选择倾向，已经很明显的显示出了混合共识的趋势。咱们是否是也能够作到这一点？以状态为中心的设计仍是以事件为中心的设计，是否是也能兼得？这正是咱们最近在作的一些尝试。若是可以同时拥有鱼和熊掌，咱们可能可以找到一种更好的区块链，尤为是公有链架构。