比特币中本聪共识的特点和优势介绍

指导

本文由 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，其中包含：

• 80 字节块头

• 短交易ID

• 发送方有但接收方没有的预测交易

最终一个1MB的区块只需要广播一个13KB的区块消息，节省了传输的每一个字节。 在这一点上，中本聪共识做得很好，没有带宽被共识协议浪费。

许多其他协议将宝贵的带宽资源浪费在成员之间的通信上。 例如，Algorand 使用大小为 300KB 的区块证书向用户证明一个区块已经提交。

3、通用性好

中本聪共识可以保证在区块生成时就可以确定全局交易顺序，兼容智能合约的编程模型。 然而，许多具有其他拓扑结构的替代协议要么放弃全局交易顺序，要么需要很长时间才能确认，这极大地限制了它们的效率提升或功能丰富。

中本聪共识在哪些方面可以改进？

1.带宽利用率不足

比特币隔离见证（Segwit）后，每个区块对应的数据增加到4MB（1MB区块+3MB隔离见证数据）； 2016 年比特币的 IPv4 节点带宽中位数为 33Mbit/s，2017 年 2 月，该数字达到 56Mbit/s，是 2016 年的 1.7 倍。带宽在没有增加比特币网络吞吐量的情况下增加。

我们可以想象，如果吞吐量可以根据带宽情况动态调整，那该多好。

2.激励问题

在中本聪共识中，自私挖矿是有利可图的，自私挖矿会增加孤块率，减少正常出块数。 在下一个难度调整周期，协议会认为挖矿难度过高，会降低挖矿难度。 这样一来，自私的挖矿方就会增加单位时间挖出的币，从而获得比正常挖矿更多的收益。

我们可以想象，如果能够避免自私挖矿该有多好。

更好的中本聪共识 - CKB Consensus

为了解决中本聪共识遇到的问题，CKB 共识带来了三点创新：

•两步交易确认：降低孤块率

• 动态调整区块间隔和区块奖励：更好地利用带宽

• 难度调整考虑了所有区块：防止自私挖矿

结果是多项改进：

• 性能改进

• 安全增强

• 公平性改进

我们稍后会一一阅读。

两步交易确认

前面提到比特币采用共识机制，在一定的带宽条件下，中本聪共识已经很好地利用了带宽比特币采用共识机制，所以要提高中本聪共识的吞吐量，只有两件事可以做：

• 更大的块

• 更短的出块时间

较大的块导致块广播中的传输时间更长。 在这个过程中，其他矿工更有可能找到一个区块，导致这个区块成为孤块； 更小的出块时间相当于降低了出块难度，更容易找到区块，同时也容易导致孤块率上升。 当孤块率达到一定程度时，上述两种方法都无法继续提高吞吐量。

此外，孤立块也会对网络的安全和性能产生很大的影响。

在安全性方面，如下图所示，高孤块率将允许攻击者以远低于51%的算力构建最长链。

在性能方面，孤立块占用带宽资源，影响网络吞吐量。

从上面的分析来看，要想突破吞吐量的限制，就需要降低孤块率。

那么如何降低孤块率呢？

孤儿块的出现是由于区块广播的延迟，而区块广播的延迟主要是由于Fresh Transactions（发送方有但接收方没有的交易）的同步。

CKB 共识使用两步交易确认来缓解这个问题。 下图是 CKB 共识中区块的数据结构：

• 区块的元信息放在区块头（header）中

•区块确认区（commitment zone）中的已确认交易

• 交易id会放在提案区，用于n个高度后的区块确认

• 叔叔标题和叔叔求婚区会放置关于叔叔的信息

每个矿工只允许打包hm和hn之间的提案区和叔块提案区内的交易。

从上图可以看出，当前高度为h（Height: h）的区块只能打包从窗口区域（hm到hn）中选出的提案区交易，叔块提案区的交易也可以被打包。 这保证了矿工总是有足够的交易来打包，从而消除了同步 Fresh Transaction 导致的区块广播延迟，最终降低了孤块率。

并且由于所有已确认交易的ids已经包含在紧凑块中，矿工不会将这部分交易包含在新块中，这样矿工就可以轻松地为交易确认做出贡献并获得手续费。

动态调整区块间隔和区块奖励

通过设置固定的孤块率，在下一个难度周期（Epoch）动态调整难度。

如果孤块率低于设定值，则意味着网络可以处理更多的交易，可以在下一个难度周期继续降低难度。 此时出块时间会减少，吞吐量会增加，出块奖励也会相应减少。

反之，如果孤块率高于设定值，则意味着网络无法处理如此多的交易，需要在下一个难度周期提高难度，这会增加出块时间，降低吞吐量，并且相应地增加区块奖励。

在 CKB 区块浏览器中，我们可以通过区块信息部分验证上述过程。

从上图可以看出，一个block包含以下信息：

•Epoch: 0 — 当前难度循环数为0

•Epoch Start Number: 0 — 当前Epoch的区块高度（block height）为0

•Epoch Length: 1250 — 当前Epoch包含1250个区块，即区块高度从0到1249

•Difficulty: 37522 — 当前Epoch难度值为37522

•区块奖励：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

•区块奖励：1491.64677805 CKB — 每个区块奖励1491.64677805 CKB

•Uncle Count: 0——叔块数为0

与Epoch 0相比，Epoch 1的难度值变大，导致吞吐量（区块数）减少，区块奖励增加，但Epoch奖励总和不变：

第 0 纪：1250 * 1000 CKB = 1,250,000

纪元 0：838 * 1491.64677805 CKB = 1,250,000.0000059

通过以上信息，可以观察到Epoch难度值因孤块率变化而发生的调整。 但是，由于目前还无法得知整个Epoch的孤块率，因此无法观察到孤块率对Epoch难度调整影响的直观联系。

防止自私挖矿

如前所述，中本聪共识中的自私挖矿是有利可图的。 研究发现，网络难度的调整只考虑了区块数量的维度。 那么 CKB 是如何解决这个问题的呢？

在 CKB 共识中，下一个 Epoch 的难度调整不仅计算确认块的数量，还考虑了孤儿块和叔块，所以攻击者无法使用自私挖矿来降低网络的难度，所以同样的计算权力不能被用来获取更多的收益，最终自私挖矿在 CKB 中变得无利可图。

最后

最后，我想强调一下 CKB 共识的优势：“CKB 共识是中本聪共识的改进版，通过三大创新，在不损害安全性的情况下提高了吞吐量，解决了自私挖矿问题.”。 不过，CKB 共识还是一个新生事物，需要时间去验证。 我们将持续关注 CKB 共识的最新进展和发现。