突破中本聪共识！公链 CKB 公布 NC-Max 共识协议

摘要：最后，在中采用了一个的变体作为共识协议，拥有更高的吞吐量。知识点，在比特币改进协议中提出，能够减少网络节点广播区块所需的带宽数量。

本期秘猿科技区块链小课堂将会就 PoW 共识的突破进行展开。带宽实际上是区块链吞吐量的最大限制，在美国旧金山举办的 Scaling Bitcoin Meetup 中，秘猿科技研究员张韧从「带宽利用率」角度分析了诸多共识协议的效率和可行性。
理解本文需要以下知识储备： 
比特币共识协议（也就是 Nakamoto Consensus）基本概念
 以太坊共识协议基本概念 
孤块、叔块、自私挖矿等概念

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

自我介绍一下，我是张韧，Nervos & Cryptape 的研究员，目前我在鲁汶大学 COSIC (Computer Security and Industrial Cryptography group) 读博士，师从 Bart Preneel。 如果你对 COSIC 不熟悉的话，不知道你是否听说过 AES，它是我们所有人的手机中使用的加密标准。

当然如果你熟悉 Bart Preneel 的话，会知道他是 RIPEMD 160 的设计者。RIPEMD 160 是比特币公钥转化为比特币地址时使用的哈希算法。

Nervos CKB 是一个公有链，能够支持各种编程语言的智能合约，以及各种各样的 Layer 2 协议。在 Nervos CKB 上你可以用任意资产支付交易手续费。在 Nervos CKB 中智能合约的执行和验证是分离的，从而达到更好的隐私和性能。最后，在 Nervos CKB 中采用了 NC-Max ——一个 Nakamoto Consensus 的变体——作为共识协议，拥有更高的吞吐量。

声明：本次分享内容仅着眼于 Layer 1 共识协议的分析，我将不会谈到 Lightning Network 这样的 Layer 2 方案。

这里是我本次分享的大纲，首先我会告诉你为什么我们会那么喜欢 Nakamoto Consensus（也就是比特币的共识协议，以下简称 NC，包含一组规则，如最长链规则、激励规则、增发规则等）。然后我会给出我们为什么不采用其他共识协议的理由。最后我会给出我们 Nervos CKB 的共识协议 NC-Max 的设计思路。

先来回答一个问题，为什么我们喜欢比特币的 Nakamoto Consensus（NC）？

有很多的理由，首先 NC 的性能优化做的非常好，它能够节约每一个传输的每一个字节，以及每个计算周期。举例来说，它使用Compact Block来加快区块的传播，可能在未来使用 Minisketch （一个用于在分布式系统不同节点之间同步信息时，降低带宽需求的软件库）来节省交易广播所需要的带宽资源。同时比特币的开发者提出了 Graftroot（关系到比特币上开发智能合约以及隐私性的一项提案），你可以认为它能够通过压缩比特币上的智能合约从而获得更好的隐私性和更好的性能。或许我们还能够看到签名聚合技术（Signature Aggregation）应用在比特币之上。

知识点：Compact Block Relay，在比特币改进协议（BIP）152 中提出，能够减少 P2P 网络节点广播区块所需的带宽数量。Compact block 是完整区块的「概要」，包含下面三部分信息： 
1、新区块的区块头 
2、交易 ID
 3、发送方节点预测的但是接收节点不具备的完整交易
接收方会尝试根据收到的信息以及在其内存池中的交易来重新构建完整区块。若仍然缺失某些交易，它将会请求广播节点。

喜欢 NC 的另一个理由是它的通用性。UTXO 模型加上全局交易顺序能够支持各种分片技术和 Layer 2 方案，以及复杂的智能合约。

相比来看，以太坊的 Account 模型进行分片的难度更高；并且如果你没有一个全局交易顺序的话，比如像许多 DAG 类型协议那样，那么就很难支持复杂的智能合约，关于这一部分会在后面谈 DAG 的时候详细描述。

我们也喜欢比特币 NC 的安全性。比特币网络经历了很多的攻击，还是稳定运行了十年。而且严格意义上来说，目前没有任何一个已知的工作量证明共识机制在整体上超越 NC。如果你对这个话题感兴趣，可以看这里。

然而在 NC 中有两个地方我们希望做出一些改变。首先在带宽利用方面，比特币的 NC 在采用隔离见证之后，人为设定了最大为每十分钟 4Mb 的吞吐量，然而现实情况是，比特币公共节点的带宽水平在过去的几年里获得了大幅度的提升。

如同上图中这个研究所指出的，链接到网络中的比特币 IPv4 节点在 2016 年时带宽中位数为 33Mbit/s，在 2017 年 2 月，这个数字达到了 56Mbit/s。

我们很容易想到的改进方式就是，协议自身是否能够动态地调节吞吐量来适应带宽水平的变化？

Bitcoin Unlimited 做了一个糟糕的尝试，它希望能够动态地调节比特币的吞吐量，但是它失败了，引入了多种新的攻击方式让它的协议变得不安全。上面是在 Coindesk 上发布的一篇关于 Bitcoin Unlimited 安全性研究（链接：https://www.coindesk.com/etf-...），我也是这项研究的参与者之一。

另一个我们希望在 NC 中做出改变的是它的激励问题，也就是出现自私挖矿攻击的问题。自私挖矿攻击者会扣留发现的区块，希望在网络中获得更大的领先优势。当其他诚实矿工发现区块的时候，攻击者会向网络广播这个被扣留的区块，寄希望于这个被广播的扣留区块会在诚实区块之前，被大部分诚实矿工接收到。如果攻击者足够幸运，下一个块是在攻击者的块上面进行挖矿的，那么诚实的块将会成为孤块。如果攻击者运气好到能够连续挖到多个区块，那么它将能够非常安全地让一个诚实矿工的区块失效，因为攻击者会有更长的链。

为什么自私挖矿是有利可图的呢？我们举一个具体的例子，假设自私挖矿攻击者有全网 30% 的算力，诚实矿工控制剩下的 70%。如果没有自私挖矿攻击出现，那么攻击者在 10 个区块中能够找到 3 个，诚实矿工找到 7 个，大家都拿到应有的报酬。如果攻击者发动自私挖矿攻击，那么它能够找到 3 个区块，诚实矿工只能找到 4 个区块，因为另外 3 个诚实矿工找到的区块经过前面提到的攻击方式变成了孤块，原本能够产生 10 个区块的时间现在只产生了 7 个区块，主链增长速度减慢。

在下一个难度调整周期，由于协议发现主链增长速度减慢，会降低挖矿难度，从而攻击者能够用同样大的算力获得更多的奖励，这是自私挖矿有利可图的原理。要注意的是，矿工获得的收益是根据单位时间内获得的币的数量而不是获得币的比例来计算的。在下一个难度调整周期，由于链增长的速度下降，协议会降低挖矿难度，此时矿工在单位时间能够获得更多的币，才有收益。因此，自私挖矿在第一个难度调整周期中是没有收益的，只有在挖矿难度调整之后自私挖矿才会有收益。

那我们为什么不选择其他替代性的共识协议呢？

目前有三种替代 NC 的方式，它们分别是 PoS（Proof of Stake，权益证明），DAG 和两种区块类型的共识协议。注意这三种方式并不是相互排斥的，是有可能同时应用它们之中的 2-3 种的。下面我们来进一步分析这些协议的安全性、功能性和吞吐量。

首先是 PoS，实际上所有的 PoS 协议引入了新的安全前提。拿 Algorand 举例来说，它要求大部分诚实用户发送的消息能够被大部分其他诚实用户在一个已知的时间范围内里面接收到。这意味着当你持有 Algorand 的 Token 时，根据协议最初的设计你需要时刻保持在线来接收消息。如果你不在线你就不是一个合格的 Token 持有者。

Cardano 的共识协议 Ouroboros 则假设所有用户有一个弱同步的时钟，并且所有消息都能够在一定时间间隔内被送达。这实际上是提出了一个非常强的假设。有很多攻击方式能够让你的挖矿设备，你的公共节点或者手机上的时钟产生偏差。并且这个方案在现实环境中实现起来也非常困难。

另外 Sleepy Protocol 也要求用户拥有大致同步的时钟。

当这些安全性假设被违反，会为这些 PoS 协议带来灾难性的后果。并且 PoS 协议引入了一些新的攻击方式，如 Nothing-at-stake Attack，Grinding Attack，Long-range Attack，这些攻击方式在 PoW 协议中是不存在的，在这里我不对这些攻击方式进行详细描述。

那么 DAG 协议怎么样呢？

所有 DAG 协议都有交易排序的问题，如像 DAG 协议那样让区块同步产生，那么不同的矿工或不同的公共节点对交易顺序的判断会有不一致：我认为这一些交易被确认了，但是其他人可能认为另一组交易是被确认的。这时候你会有两种解决问题的思路。

一种是在区块链拓扑排序完成之后对交易进行排序，这意味着你需要等待很长的交易确认时间。

另一种是不去确认交易顺序。合约的输入需要全局的交易顺序，如果不同矿工判断的交易顺序不同，那么每个矿工对合约逻辑执行顺序的理解就是不一样的，特别是对于复杂的合约。这会限制合约的功能性，复杂合约不能执行，合约中包含的 Token 会卡在合约中。

那么那些有两种区块类型的协议如何呢？两种区块类型的协议，顾名思义，它采用一种和 NC 中的区块一样的关键区块（Key Block）来保障交易确认的安全，同时在两个关键区块之间广播微区块（Micro Block）来提高吞吐量。

这些协议通常和 DAG 协议一样会有较长的确认延迟。Bitcoin NG 就采用了上述的方案。在 Bitcoin NG 的论文中明确表明，若用户需要确保交易确认，在 Bitcoin NG 中他们就需要等待数个关键区块的确认，忍受较长的交易延迟。

（原本在分享过程中张韧提到 Byzcoin 也有类似的问题。但是经过进一步分析发现问题并不类似，若对 Byzcoin 感兴趣可以点击「阅读原文」在论坛进一步讨论 ）。

所有采用这些替代性共识协议的项目都声称它们有很高的吞吐量，那么这些项目的吞吐量究竟如何呢？（下面这一段建议观看视频，约在 15:30 部分，现场非常精彩 ）

Solana 声称能够每秒能够处理 710000 笔交易。如果你能够有这么大的突破，理应获得图灵奖。我迫不及待地想听到他们获奖的消息。

还有这个名为 NKN 的协议，他们声称他们能够在全网拥有 10000 个节点的同时每秒处理 100 万笔交易，目前我还不知道他们是如何做到的，但是我对他们实现的方式非常好奇。

我也很好奇为什么 Stellar 和 Ripple 也将自己的协议归类为 NC，我也非常好奇 10000 个节点如何实现每秒处理 100 万笔交易的。

而如果你想做个梦的话，你最好做一个伟大的梦，比如这个协议。它声称能够在低于 1 秒的最终确认时间内拥有 1000000000000TPS 。

嗯，我真的觉得地球对他们而言已经不够大了，他们真的需要另找一个更大的星球来部署他们的协议。

我们要注意的是，自称的 TPS 是没有可比性的。因为它们是在不同的网络环境中做模拟，某些模拟甚至使用 1Gbit/s 的带宽，显然这和现实网络情况相差甚远。

并且这些协议都忽略了真实的情况。他们之中没有一个考虑到交易的同步。对它们来说似乎所有的交易都是已经在区块中同步好的一样，共识协议只是用来对交易进行排序的。而且一些模拟假设委员会成员（节点）之间有直接的连接，但事实是，在公有链网络中所有的消息都是通过广播进行的，而广播消息会占用公共节点的带宽。

知识点：Fresh Transaction，为什么说要考虑交易的同步呢？要认识到，在比特币中一个用户从钱包客户端发起的交易并不是被所有矿工都接受到，而是相邻的几个矿工。这些矿工在接受到用户发起的交易的时候会对交易进行验证才能放到交易池中，以便在未来将这些交易打包出块。因此若一个矿工成功挖到一个块并广播 Compact Block，其他矿工在检查 Compact Block 中交易 ID 的时候若发现对应的有些交易并不在自己的交易池中，则需要向发送方请求完整交易进行验证来保障区块中所有交易都是合法的，这些交易就是「Fresh Transaction」。若不进行验证就在收到区块之后挖矿，一旦完整区块广播后被发现有非法交易，将不会被矿工认可，在这个非法区块之后挖出的区块都会作废。Fresh Transaction 的概念我们会在后面用到。

这里我们有一个评估 TPS 的模型。如图所示，首先我们相信所有公共节点的带宽是有一个上限的，最多能够使用 100% 的带宽，你不能使用超过 100% 的带宽。在这里带宽的占用有三个组成部分。

如上图所示，第一部分是用于同步最终确认的交易所占用的带宽比例，这一部分是真正的 TPS（This is the real TPS）。交易首先要被同步，之后才能进行交易确认。第二部分是被共识协议「浪费」的带宽所占的比例。第三部分是未被利用的带宽。

所以如果想要提高 TPS，能够做的只有两件事。

1、降低共识协议占用的带宽比例
2、降低未被利用部分的带宽比例

能做的只有这两件事情，对，没有其他的方式了，并且对于 Layer 1 的协议带宽占用不能超过 100%。

那我们先来看看其他替代性共识协议的带宽占用。

事实上，很多协议将它们珍贵的带宽资源浪费在委员会成员之间的通信上。

Algorand 存储区块证书以此来向新用户证明一个区块被提交。每个区块证书的大小是 300KB ，独立于区块容量限制之外。如果你按照一个区块 1MB 的大小来计算，那么这意味着大约 25% 的带宽会永远被用于同步这些证书。因此我非常好奇为什么它们声称他们的吞吐量比 NC 更好，这根本不合理。

另外一种在共识协议中浪费带宽的方式是区块型 DAG 和孤块中的冗余交易。如上图的论文中所说，如果所有的节点在区块中选择包含同样的一组子交易，任何两个平行创建的区块将可能出现冲突，并且吞吐量就不会很高。

而目前所有的区块型 DAG 协议对这种情况视若罔闻。

从上面的分析中看到，显然目前的吞吐量不能满足我们，因此，Nervos CKB 的共识协议 NC-Max 对 NC 做了一些改进：

NC-Max 有三个主要的创新

采用两步交易确认来降低孤块率

动态调整区块间隔和区块奖励来更好的提升带宽利用率

在难度调整的时候考虑周期中的所有区块，来抵御自私挖矿攻击。

接下来我会进行详细解释。

NC 有一个天然的吞吐量限制，因为想要提高 NC 中的吞吐量，只能做两件事情：

第一件是更大的区块，就如 Bitcoin Unlimited 和 Bitcoin Cash 那样，还有很多其他的项目也这样做；

第二件是降低出块间隔。

但是由于区块广播需要时间，广播期间若其他节点发现区块并广播，会和正在广播的区块产生竞争，其中之一会成为孤块。更大的区块会需要更长时间广播，降低出块间隔实际上是降低出块难度，节点更容易发现区块。这两种方案容易带来的结果是孤块率变高了。这些孤块占用更多的带宽，但是它们并不为交易确认做出贡献。当孤块率提高时，系统的安全性会降低并且吞吐量也会降低。因此对于这两种方案最终会达到一个平衡，当区块大小或出块间隔调节到一定程度时，孤块率会高到一定程度，即使你进一步增加区块大小或者降低出块间隔，吞吐量也不会得到提高。

为什么太多的孤块会对网络的安全和性能产生负面影响呢？在上图中我们能够看到，当孤块率非常高时，攻击者能够非常轻易地私自构建一条更长链。攻击者只需要拥有比全网算力的 51% 低很多的算力，就能够覆盖掉区块链。并且孤块会消耗公共节点大量的带宽，这会对整个系统的吞吐量造成很大的负面影响。

那我们如何打破 NC 吞吐量的限制呢？经过上面分析，如果我们想要打破这个限制，就必须降低孤块率。如果孤块率下降，那么网络的安全性和吞吐量都能够提高。

如何降低孤块率呢？孤块的出现是由于区块广播的延迟，若在一个区块广播的过程中，有另一个区块被发现，那么其中一个区块就注定会成为孤块。如果区块广播能够瞬间完成，自然不会有孤块出现。那我们如何确保区块能够足够快速地被广播出去呢？

比特币的开发者已经投入了非常多的资源和精力来加快区块的广播速度，我们需要进一步找出哪些区块的广播速度较慢，或是出了问题。

我们来详细看看这是如何发生的，请看下图。

目前的比特币网络，如果一切顺利的话，一个区块是通过一个Compact Block 中继协议来广播的。

在 Compact Block 中，并不会将整个交易（比特币每个交易大约 250Bytes）广播出去，而是广播 Compact Block 中的交易 ID。这些交易 ID 组成了 Compact Block，这些 Compact Block 比实际的区块小很多，因此速度会快很多。

当节点 A 广播 Compact Block 给节点 B 的时候，节点 B 检查这些交易 ID ，如果对于节点 B 这些交易都不是 Fresh Transaction（也就是节点 B 的交易池中包含这些交易），节点 B 能够立刻转发这些 Compact Block 给相邻节点，这种情况非常棒，过程很顺利。

然而如果在 Compact Block 中有 Fresh Transaction，节点 B 将首先需要从节点 A 那边同步 Fresh Transaction，然后验证这些交易的签名，这些步骤都很耗费时间。只有当整个区块都经过验证无误之后，节点 B 才能继续广播这个区块。这个过程避免收到的区块非法，这样矿工才会在这个区块之后挖矿并广播，若不经过验证万一之后发现是非法区块，那么在这个非法区块之后的区块都是无效的。同步 Fresh Transaction 的过程是比特币区块广播延迟的主要原因。

所以，以太坊是一个糟糕的尝试，我来分析一下他们是怎么做的。以太坊简单地缩短了出块间隔，但是以太坊有一个问题，就是它不能够在收到区块之前验证交易的有效性。因为在以太坊中一个交易的有效性依赖于区块中交易的顺序，因此如果你想要验证一个交易的有效性你必须等到整个区块都被接收到才行，这样的话每一个区块实际上都是 Fresh Transaction。

并且以太坊的网络协议维护得非常差，自从 2015 年开始就没有任何的迭代。

而且在交易广播过程中也有大量的冗余。以太坊客户端会将同一笔交易向不同的节点广播 7 次，这意味着每一个节点将会收到同一笔交易 7 次。（以太坊有不同的客户端，如 Parity Ethereum，Geth 等）而且不同类型的客户端之间有不一致性，两个主要的以太坊客户端之间基本都是独立的。

因此能够链接两个不同的网络的节点非常少，这也是为什么以太坊孤块率有时会高达 30%，并且交易吞吐量非常低。

而且大矿工没有加快区块广播速度的激励。因为如果我的区块能够更慢地广播出去，意味着我实际上能够实现「自私挖矿」（这里大矿工并不扣留区块，只是区块广播比较慢，在这个过程中出现了其他的竞争块，而因为我是大矿工有较大的概率在和其他竞争块竞争过程中胜出）。这对我来讲是好事，为什么我要加速区块广播呢？

以太坊中的叔块奖励也没有提供任何帮助，毕竟如果产生了的孤块，矿工还是能够获得奖励。因此小矿工会采用先广播区块头和空块的方式，因为广播区块头的速度会快很多。并且由于不知道下一个区块中会包含哪些交易，因此矿工通常会挖一个空块来确保区块中不会包含和之前区块交易产生冲突的交易。这非常糟糕，因为空块并不为交易确认做出贡献。

下面是我们的设计，来缓解上面提到的一些问题。

这张图是区块的结构，我们在比特币区块结构的基础上增加了几个字段。

上图是我们的完整区块的区块结构。首先我们有一个交易提案区（青色区域）。只有交易提案区可包含 Fresh Transaction，而传统的交易确认区（橙色区域）只能包含前几个区块的交易提案区的交易，若当前区块高度是 h 的话，那么就是 h-m 到 h-n 区块的交易提案区内的交易。只有这些交易能够被确认，Fresh Transaction 不能被交易确认区确认。交易提案区不包含完整的交易，只包含交易 ID（Truncated Transaction ID），因此交易提案区会非常小。

在叔块头区可以包含任意数量的叔块（紫色区域），叔块应该包含它们的区块头和交易提案区。叔块头区不计入区块大小，因而不受区块大小的限制，所以不会限制矿工添加叔块。

下面我进一步来解释交易提案区。这个区域非常小，因为它只包含交易 ID。完整的交易与区块同步广播，因为这是一个并行的过程，所以交易的广播不会影响到区块的广播。并且节点在收到广播的交易后只需要验证哈希，不会影响区块的验证过程。

尽管这意味着在交易提案区可能会有无效的交易，双花交易以及矿工可能不愿意接受的交易，但是这都没有关系。

类比之前提到的比特币区块广播过程，在我们的协议中，发现区块的节点会先广播 Compact Block（也就是区块头和交易的 ID），Compact Block 较比特币的稍微大一点，包含交易提案区和若干叔块的区块头和叔块的交易提案区。但由于 Compact Block 本身足够小通常会立刻广播给相邻的节点。

新提出的交易，如果有一部分不在节点的交易池中，它们会在发出 Compact Block 之后进行广播。这些都是并行过程，不会相互影响。节点收到交易，经过哈希验证后广播给相邻的节点。

这很自然地会有几个问题：

如果矿工拒绝提供提案交易的完整版本怎么办？

我把这个交易放到我的交易提案区，但是当你问我要完整的交易的时候，我装作不知道。

实际上这个对区块广播不会有影响，因为不论交易提案区是否有 Fresh Transaction，区块都能够广播。

并且其他矿工也会继续挖矿，因为总是有足够的提案交易需要确认。该矿工也没有必要挖空块，因为之前区块的交易提案区包含了它将打包的这些交易 ID，已经被发现的区块在 Compact Block 中都广播了打包进的交易确认区的交易 ID，矿工都知道哪些交易被打包了哪些没有，不会选择和被发现区块交易确认区内相冲突的交易，因此矿工会选择继续打包交易出块并获得手续费，为交易确认做贡献。

那么如果矿工在他们最新的区块中包含了这些提出但未广播的交易，以获得一个类似自私挖矿的优势怎么办？

在比特币的 NC 中，矿工减慢区块广播速度可以获得挖矿优势。矿工通常能够在挖出一个区块时，只广播区块头，而在广播完整区块的时候放慢动作。在这个过程中只有该矿工能够挖矿（因为只有他知道下一个区块的信息，能够基于这个新块挖矿，这个过程类似扣留区块）。

但是在我们的协议中，采用这种方式只会减慢 n 个区块之后的区块广播速度。因为提出但未广播的交易只有自私矿工知道，也只有自私矿工能以此作为优势。然而这个不能被用在下一个区块中，因为在我们的协议中只能挖 n 个区块之前提案区中包含交易，中间需要有一个间隔。

矿工只能够挖 h-m 至 h-n 个区块内的提案交易，但是不能挖前一个区块的提案交易，除非这个区块也是被攻击者挖到的。

如图所示，这是我们的共识协议和比特币 NC 的对比。在比特币 NC 中当自私的矿工找到区块 h， 它能够立刻开始挖区块 h+1，此时诚实矿工只能够在收到完整的区块 h 之后才能开始挖矿，因为其他矿工需要知道区块包含的完整的交易并验证来确定区块是合法的，而自私矿工能够通过减慢区块 h 传输的速度来让其他矿工更晚收到区块。在区块广播期间就是自私挖矿者的优势期。

然而在我们的协议中当一个自私矿工找到一个区块 h，广播了包含区块头和交易 ID 的 Compact Block，诚实矿工能够立刻开始挖 h+1。如果自私矿工想要利用这些提出但未广播的交易，它必须找到 n 个区块之后的区块（这些区块才能包含这些提出但未广播的交易），这样他们才能利用这个优势。然而这很难发生，你不能确定在 n 个块之后的那个块是你挖出来的，这个非常难预测。

为了更好地利用带宽，我们的协议使用了另一种不同的难度调整机制，设定一个固定的孤块率（根据上一个难度调节期的叔块数来计算）。

如果孤块率在上一个难度调整周期低于设定的孤块率，挖矿难度会降低，出块间隔将降低，吞吐量会提高。也就是说，更少的孤块意味着当前的网络状态实际上有能力更快地同步交易，我们能够在提高吞吐量的同时不损害网络的去中心化。

反过来看如果难度提高，那么出块间隔会增加，吞吐量也会降低。如果孤块率很高那么意味着当前的网络在这个难度调整周期内并不能处理那么多的交易，那么协议就会降低吞吐量。

同时出块奖励会和 1/（预期出块间隔）成正比，因此在每个难度调整周期中预期的总出块奖励是固定的。

这意味着假设我们每十分钟出一个块，每个块中有 12.5 个比特币，如果难度调节变成每 5 分钟出一个块的时候，每个块会有 6.125 个比特币。因此货币的发行率也是保持恒定的。

最后，抵抗自私挖矿攻击。前面我们提到我们的协议和 NC 的一个区别在于，我们的难度调整机制是根据难度调整区间中出现的所有区块来计算的，在估计总算力的时候也会包含叔块。

在 NC-Max 中，假设攻击者占总算力的 30%，诚实矿工 70%，如果没有自私挖矿攻击，在 10 个区块中攻击者能够找到 3 个区块，诚实矿工找到 7 个。如果进行自私挖矿，攻击者在 7 个区块中能够找到 3 个区块，诚实矿工找到 4 个，3 个诚实区块会成为孤块，主链会增长缓慢。

前面也提到自私挖矿在第一个难度调整周期内是没有收益的，那么在第二个难度调整周期会出现什么？

在下一个难度调整周期，难度会保持不变（因为难度会根据所有区块计算，包含孤块），攻击者并不能用同样的算力找到更多的区块，因此自私挖矿不再有利可图。

也就是说，我们假设币价在短时间内维持稳定，由于自私挖矿攻击者是短视的，他们的奖励是根据单位时间内获得的奖励来定义，可以等价于同样的电力消耗能够获得的奖励。在比特币中，自私挖矿攻击者能够通过降低链增长速度，「迫使」协议降低出块难度，从而在难度调整之后单位时间内能够获得更多的奖励。而在 NC-Max 协议设计中，出块难度会根据所有区块来计算，包括孤块，攻击者让诚实矿工的区块成为孤块，却并不能「迫使」协议降低出块难度，以在单位时间内获得更高奖励。

最后总结一下，我们的协议会很好地利用孤块：

我们希望能够通过两步交易验证来降低孤块数量，在孤块数量降低之后，我们利用孤块率作为一个带宽利用水平的指标来动态地调节吞吐量。

并且孤块信息被写在了区块链中，我们在挖矿难度调整算法中利用这个信息从而让自私挖矿无利可图。