导读作为行业的代表，手游传奇发布网需要给同行们做出一定的表率，在产品质量上要一路领先才可以。
本文是rebase社区的harry在《全名挖矿月》nervos专场活动上做的分享。
比特币共识也称为中本聪共识（nakamoto consensus），经历了10年的运行证明了它的安全性和众多优点，不过中本聪共识也因为它的吞吐量不高一直饱受诟病。ckb共识是中本聪共识的改进版，通过三大创新，在不妥协安全性的前提下，实现了吞吐量的提升，并解决了自私挖矿的问题。
中本聪共识的优点
1安全性高
中本聪共识经历了很多的攻击，仍然稳定运行了十年。而且，目前没有任何一个工作量证明机制整体超越中本聪共识。其它的协议要么有很强的安全假设，要么会引入新的攻击。
?安全假设: 比如使用pos的algorand要求持有token的人时刻保持在线来接收消息。
?新的攻击: pos的nothing-at-stake attack，long-range attack，这些攻击在pow中是不存在的。
2带宽利用好
在带宽利用方面，我们可以用一个简单的模型来衡量共识协议的吞吐量。
最左侧蓝色的部分是用来同步最终确认交易的带宽比例，这部分是真正的tps；中间红色部分是被共识协议“浪费”的带宽比例；最右侧白色部分是未被利用的带宽。
在带宽一定的情况下，想要提高 tps，能够做的只有两件事:
1）降低共识协议“浪费”的带宽比例
2）降低未被利用部分的带宽比例
为了加快区块的传播，中本聪共识使用了compact block relay，compact block中包含:
?80字节的区块头
?短交易id
?预测的发送方有而接收方没有的交易
最终1mb的区块只需要广播13kb的区块消息，节约传输的每一个字节。在这一点上，中本聪共识已经做得非常好了，没有被共识协议浪费什么带宽。
其它很多协议，它们将珍贵的带宽资源浪费在成员间的通讯上，比如algorand用一个大小为300kb的区块证书来向用户证明一个区块被提交。
3通用性好
中本聪共识可以确保在区块生成时就能确定全局交易顺序，这是和智能合约的编程模型相兼容的。而很多其他拓扑结构的替代协议要么放弃全局交易顺序，要么需要经过很长的时间才能确认，这极大地限制了其效率上的提升或者功能上的丰富。
中本聪共识哪些地方可以改善
1带宽利用不足
在比特币隔离见证（segwit）之后每个区块对应的数据增加到了4mb（1mb区块+3mb隔离见证数据)；比特币的ipv4 节点带宽中位数在 2016 年时是33mbits，在 2017 年 2 月，这个数字达到56mbits，是2016年的17倍。带宽增加了，而比特币网络的吞吐量却没有增加。
我们可以想到，如果能够根据带宽状况来动态调节吐吞量就好了。
2激励问题
中本聪共识中，自私挖矿是有利可图的，自私挖矿会增加孤块率，使得正常的出块数量减少。在下一个难度调整周期，协议会认为挖矿难度太高，会降低挖矿难度，结果会使自私挖矿一方在单位时间内挖到的币增加，从而获得比正常挖矿更多的收益。
我们可以想到，如果可以避免自私挖矿就好了。
更好的中本聪共识——ckb共识
为了解决中本聪共识遇到的问题，ckb共识带来了三个创新：
?两步交易确认: 降低孤块率
?动态调整区块间隔和区块奖励: 更好的利用带宽
?难度调整考虑所有区块: 防止自私挖矿
结果带来了几个方面的提升:
?性能提升
?安全提升
?公平性提升
后面我们一一解读。
两步交易确认
前面提到，在带宽条件一定的情况下，中本聪共识已经对带宽进行了非常好的利用，所以提升中本聪共识的吞吐量只能做两件事:
?更大的区块
?更小的出块时间
更大的区块导致了在区块广播是需要更多的传输时间，在这个过程中，其它的矿工就有更大的可能发现一个区块，导致这个区块成为孤块；更小的出块时间相当于降低了出块难度，让发现区块更容易，也容易导致孤块率的增加。当孤块率高到一定程度，上面两个方法都不能让吞吐量继续增加。
而且孤块还会对网络的安全和性能产生很大的影响。
安全方面，如下图，孤块率高会导致攻击者可以以远低于51%的算力构造出一条最长的链。
性能方面，孤块会占用带宽资源，影响网络吞吐量。
从上面的分析，要想打破吞吐量的限制，就需要降低孤块率。
那如何降低孤块率呢？
孤块的出现是因为区块广播的延迟，而区块广播的延迟主要是因为同步fresh transaction（发送方有而接收方没有的交易）。
ckb共识采用两步交易确认来缓解这个问题。下图是ckb共识中区块的数据结构：
?区块头（header）中放置区块的元信息
?区块确认区（commitment zone）中是确认的交易
?提案区（proposal zone）中会放置交易id，用于n个高度后的区块的确认
?叔块头（uncle headers）和叔块提案区（uncles' proposal zones）会放置叔块的相关信息
每个矿工只允许打包前面h-m到h-n之间提案区以及叔块提案区的交易。
从上图中可以看到，当前高度为h（height: h）的区块只能打包从window区域内（h-m到h-n）挑选出的提案区交易，叔块提案区的交易也可以进行打包。这就保证了矿工总是有足够的交易可以打包，从而消除了同步fresh transaction带来的区块广播的延迟，最终降低孤块率。
而且因为在compact block中已经包含了所有已确认交易的id，矿工在新区块中不会将这部分交易包含进来，让矿工可以很容易的为交易确认做贡献，并获得手续费。
动态调整区块间隔和区块奖励
通过设定一个固定的孤块率，在下一个难度周期（epoch）动态调整难度。
如果孤块率低于设定值，说明网络可以处理更多的交易，在下一个难度周期可以继续降低难度，这个时候出块时间将会降低，吞吐量会增加，区块奖励会相应减少。
反过来，如果孤块率高于设定值，说明网络处理不了这么多交易，在下一个难度周期应该提高难度，会使出块时间增加，吞吐量会下降，区块奖励也相应增加。
在ckb区块浏览器（explorernervosorg）中，我们可以通过区块的信息来部分验证上面提到的过程。
从上图中可以看到，一个区块包含了以下信息:
?epoch: 0 — 当前的难度周期序号为0
?epoch start number: 0 — 当前epoch开始的区块高度（block height）为0
?epoch length: 1250 — 当前epoch包含了1250个区块，也就是区块高度从0到1249
?difficulty: 37522 — 当前epoch难度值为37522
?block reward: 1000 ckb — 每个区块的奖励为1000 ckb
?uncle count: 0 — 叔块数量为0
这些信息在当前epoch 0中的1250个区块中都是相同的。
在下一个epoch，也就是从区块高度为1250开始，挖矿难度值有一定的变化（如上图）:
?epoch: 1 — 当前的难度周期序号为1
?epoch start number: 1250 — 当前epoch开始的区块高度（block height）为1250
?epoch length: 838 — 当前epoch包含了838个区块，也就是区块高度从1250到2088
?difficulty: 75044 — 当前epoch难度值为75044
?block reward: 149164677805 ckb — 每个区块的奖励为149164677805 ckb
?uncle count: 0 — 叔块数量为0
epoch 1相对于epoch 0难度值变大，导致吞吐量（区块数量）减少，区块奖励增加，但是epoch的奖励总和没有变化:
epoch 0: 1250 * 1000 ckb = 1,250,000
epoch 0: 838 * 149164677805 ckb = 1,250,0000000059
通过以上的信息可以观测到由于孤块率的变化引起的epoch难度值的调整。但由于目前还无法知道整个epoch的孤块率是多少，所以无法观测到孤块率对于epoch难度调整的影响的很直观的联系。
防止自私挖矿
前面提到，中本聪共识中自私挖矿是有利可图的，研究发现是因为网络难度的调整只考虑区块数量这一个维度。那ckb是如何解决这个问题的呢？
在ckb共识中，下一个epoch的难度调整不只是计算已确认区块的数量，还会将孤块以及叔块考虑进来，因此攻击者不能使用自私挖矿的方式来使得网络降低难度，所以也不能使用同样的算力获得更多的收益，最终自私挖矿在ckb中变得无利可图。
最后
最后再强调一下ckb共识的优点：“ckb共识是中本聪共识的改进版，通过三大创新，在不妥协安全性的前提下，实现了吞吐量的提升，并解决了自私挖矿的问题“。但ckb共识还是一个新生事物，需要时间的验证，我们也会持续的关注ckb共识的最新进展和发现。