前言：我们知道，很多PoS加密货币，其实是比特币代码库的分叉（或者至少是其后代），关键的区别在于，它们用币的所有权证明（PoS）取代了比特币的工作量证明（PoW）。然而，一些设计思想被不安全地复制，导致这些币种出现了一些新的漏洞，而它们在比特币父代码库中是不存在的。

本文公开了由Sanket Kanjalkar（sanket1729，[email protected]）、Yunqi Li、Yuguang Chen、Joseph Kuo和Andrew Miller组成的学生小组在去中心化系统实验室（Decentralized Systems Lab）调查的一系列资源耗尽漏洞。这些漏洞总共影响了26种以上的权益证明（PoS）加密货币，并允许持有少量权益的网络攻击者破坏运行相应软件的任何网络节点。这次研究是从2018年10月份开始的，并且研究人员已在文章公开之前通知了受影响的加密货币开发团队，他们当中的大多数已部署了缓解措施。

(图片来自：itradeico)

权益证明（PoS）加密货币，尤其是基于PoSv3（第三版本PoS）的那些币种，它们和比特币是很相似的，因为它们使用的是UTXO模型和最长链共识规则。关键的区别在于，它们用币的所有权证明取代了工作量证明（PoW）。

PoS机制的潜在好处包括减少环境影响，以及更好地抵御51%攻击。事实上，很多PoS加密货币是比特币代码库的分叉（或者至少是其后代），然后植入了PoS机制。然而，一些设计思想被不安全地复制，导致这些币种出现了一些新的漏洞，而它们在比特币父代码库中是不存在的。

我们将这些漏洞称为“伪造权益”攻击。本质上，它们之所以起作用，是因为PoSv3实现在提交宝贵的资源（磁盘和RAM）之前没有充分验证网络数据。其结果是，没有太多权益（币）的攻击者（在某些情况下甚至不需要币）可通过伪造数据填充受害者的磁盘或RAM，来导致其节点崩溃。我们认为，所有基于UTXO和最长链PoS模型的加密货币都很容易受到这种 “伪造权益”攻击。本文的最后，列出了经研究人员调查并被认为会受影响的加密货币列表。

在本文的其余部分，我们将详细解释漏洞和攻击，因为它们有一些微妙的后果。虽然漏洞本身在事后看来是很简单的，但要完全解决这一问题却是很棘手的，迄今为止各项目方所采用的缓解措施，都是以链分裂风险为代价的（稍后将详细介绍）。

背景

在深入研究这些漏洞的细节之前，我们先介绍一下基于PoS机制的链是如何工作的。

PoS挖矿：

与工作量证明（PoW）挖矿类似，PoS中的挖矿也包含比较区块头的哈希值和难度目标。PoS的高层次目标是确保每个利益相关者挖掘下一个区块的机会与他们持有的token数量成正比。为了实现这一点，在基于PoS的区块链中，哈希不仅取决于区块头，还取决于利益相关者插入区块中的特殊“CoinShare”交易中包含的币数量。关于PoS挖矿的完整细节，你可以在Earlz的博客文章中找到一个详尽的解释。对于这篇文章，重要的是检查 PoS取决于

1) coinstake交易，2) 以及被coinstake交易所使用的UTXO。

工作量证明（PoW）在保护区块验证资源方面的作用：

众所周知，PoW在比特币共识中起着至关重要的作用。但是，PoW也起到了第二个不太被重视的作用：即保护对节点有限资源（如磁盘、带宽、内存和CPU）的访问。在无许可的加密货币网络中，对等节点不需要信任。因此，为了防止资源耗尽攻击，比特币节点在提交更多资源（如将区块存储在RAM或磁盘上）之前，首先会检查 PoW是否有任何接收到的区块。然而，事实证明，检查PoS比验证PoW要更复杂，其对环境也更加敏感。因此，很多基于PoS的链实现，忽略了适当的验证。

为了理解这是如何导致资源耗尽漏洞的，我们必须在验证之前提供一些关于如何存储区块的详细信息。一个节点不仅必须在当前时刻跟踪最长链，还必须跟踪链的分叉数（其中任何一个都可能会成为最长链，在这种情况下，节点需要“重新组合”才能切换到它）。这可能发生，例如，在一次拙劣升级、一次双花攻击（等51%攻击）或在一次临时网络分区期间。

验证这些脱离主链的区块是困难的。要完全验证这些区块，你需要前一区块时间的一组未用币（UTXO）。比特币将UTXO集保留在了最佳链的当前尖端，而不是在过去的其他区块。有两种主要方法可以完全验证分叉上的区块：

1. “回滚”当前视图（UTXO集）到分叉开始前的点
2. 或存储所有早期区块的UTXO集副本。

比特币的代码库不支持选项2，即使这样做，也会增加存储成本（比特币节点性能依赖于大量删减不需要的数据）。选项1正是比特币代码库当前处理reorg的方式。但是，这可能非常昂贵，因此回滚和完全验证将延迟到最后一个可能的时刻，此时分叉中的工作量证明已经大于当前的主链。因此，当对等端第一次收到一个不是最长链的区块或区块头时，将跳过完全验证，并将该区块保存到本地存储。

在将区块存储到磁盘之前，比特币代码库根据PoW执行一些初步验证（但忽略交易）。此初步检查仅依赖于前一个区块头和当前区块头，因此节点可以非常快速地执行此操作。这是一个有效的防御，因为其生成有效的POW，通过它是非常昂贵的。也就是说，虽然我们可欺骗比特币节点在磁盘上存储一个无效的区块，但进行这样的资源耗尽攻击，其代价是非常昂贵的。

PoS中类似的初步检查，是验证coinstake交易，并检查与当前一个区块的内核进行哈希时，它是否通过难度目标。计算coinstake 交易的哈希是很容易的，而困难的部分是检查coinstake交易的输入UTXO是否有效和未使用，因为这需要检查UTXO集，正如前面提到的，该集对于过去的区块是不可用的。由于完全验证coinstake 交易是困难的，大多数基于PoS 机制的链提供了启发式或近似检查。结果表明，这些近似值往往不充分，可被加以利用。

漏洞#1: 不需要权益的攻击

当我们第一次调查这个问题时，我们发现有5种加密货币：Qtum（量子链）、Particl、Navcoin、HTMLcoin以及Emercoin表现出这一漏洞的相当轻微的形式：即在将区块提交到RAM或磁盘之前，它们根本没有检查任何coinshare交易。这五种加密货币的共同点是，它们采用了比特币的“区块头优先”功能，其中，区块传播被分成两条单独的消息，即区块和区块头。节点只有在区块头通过PoW检查才会请求区块，而它是最长（或更长）链。由于coinstake交易只存在于区块当中，而不存在区块头中，因此节点无法单独验证区块头。相反，它直接将区块头存储到内存中的数据结构（mapBlockIndex）。因此，任何网络攻击者，即使他们不持有币，也可以填满受害者节点的RAM。

这种攻击的第二种变体，可针对相同的代码库执行，尽管它的工作方式略有不同，且目标是不同的资源（即受害者的磁盘而非RAM）。有争议的是，涉及磁盘的攻击对受害者更有害：如果RAM已满，节点崩溃，则只需重新启动即可。但是，如果磁盘已满，则需要手动干预（例如，运行外部脚本以清除磁盘上的过时区块）。

当接收区块而不是接收区块头时，会执行不同的初步检查。理想情况下，由于区块确实包含coinstake交易，因此节点软件应在将区块提交到磁盘之前检查这个coinstake交易。但是，如前所述，如果区块位于分叉上，那么节点无法轻松地访问coinstake交易所使用的UTXO。也许正因为这个原因，这些代码库并不能验证coinstake交易。

这些漏洞中的任何一个，都可以在不持有币的情况下对加密货币进行攻击。RAM版本的攻击相对微不足道，但出于技术原因，磁盘版本的攻击需要稍微多加小心。这些细节将在2019年的《金融密码学》上发表的一篇短文中加以解释。

漏洞#2:伪造权益攻击

通过跟踪这些代码库的“血统”，我们注意到，在将比特币的“区块头优先”功能合并到PoSv3代码库的情况下，漏洞#1就会被引入。攻击不适用于早期版本的PoS币（例如点点币），因为在磁盘上存储区块之前，还需要进行两次额外的初步检查：

1. 检查正在使用的输出是否存在于主链当中；
2. 检查PoS内核哈希是否满足难度目标；

检查1是通过在交易数据库（TxDB）中进行查找来完成的，该数据库跟踪当前主链中迄今所有的交易。换言之，初步验证优于不验证，但仍然劣于完全验证。如果你一直遵循这个解释，两个问题可能会突然出现在你身上：

关注点A：检查1可确保币存在，但不能确保它未被使用。这种洞察立即导致我们接下来会讨论到的漏洞。

关注点B：即使我们在验证主链分叉上的区块，coinstake交易也会针对主链本身的TxDB进行验证。

基于问题A，我们也找到了一种欺骗这类检查的方法，我们将这种微妙的攻击方法称为“花费权益攻击”。为了绕过检查1，我们使用了一个输出，该输出由节点看到，但已被占用。通常，为了绕过检查2，我们需要挖掘一个通过难度目标的有效区块，而这又需要大量的币。然而，事实证明，我们可利用不完全验证，使用我们称之为“权益放大”的技术生成任意数量的表观权益。

权益放大（Stake Amplification）技术

为了通过少量的权益实施攻击，攻击者必须放大其表观权益。表观权益是指总的候选权益输出，甚至是已花费的权益输出。如果攻击者以数量为k的UTXO开始，那么攻击者可以创建多笔交易，将币花回攻击者，如下图所示。只有UTXO(n+1)才允许进行权益增值（staking），但是由于上面的检查2，我们可以从1到n+1的所有UTXO进行权益增值，从而使表观权益增加为n*k。这增加了找到PoS区块的机会，因为攻击者可以继续这样做来增加其表观权益。具体过程如下图左侧的“权益放大步骤”所示。

权益放大和花费权益攻击

例如，即使在系统中只拥有0.01%的权益，攻击者也只需要通过5000笔交易来挖掘具有50%的表观权益权力的区块。在攻击者收集了大量表观权益之后，他可使用新收集的表观权益输出继续挖掘PoS区块，最后，攻击者用无效区块填充受害者对等节点的磁盘，如上图右侧所示。例如，攻击者可以从交易所购买一些PoS币，如我们所描述的那样通过自我花费扩大表观权益，然后将这些币卖给交易所，并在之后的任何时候执行攻击。攻击者唯一要付出的代价就是交易费用。

协调漏洞披露

我们首先在Particl和Qtum加密货币的背景下调查了漏洞#1，为了确定这种漏洞的影响，我们从coinmarketcap.com（2018年8月9日）按市值排序，收集了已知加密货币的列表，并选出了PoS共识类型的链。我们只研究了那些从比特币代码库分叉出去的PoS币种，总共检查的加密货币共有26种，其中只发现5种PoS币受到该漏洞的影响，它们分别是Qtum, Navcoin, HTMLcoin, Emercoin和Particl，而我们的攻击方式对其余的PoS币似乎都不起作用。为了确认漏洞，我们在五个受影响的代码库中分别实施了攻击。我们利用了比特币软件中现有的测试套件，特别是regtest模式，该模式支持模拟时间戳并易于创建区块，以及基于python的测试节点（基于比特币测试框架），该节点可通过攻击者行为进行扩展。我们使用Docker容器将这些测试、它们的依赖项和受影响的特定提交哈希，打包到一个再现性工具包中，而这个工具包，我们可以轻松地将其分享给五个受影响的开发团队，以此作为漏洞公开的一部分。

然后，我们更深入地了解为什么未受影响的加密货币不易受到漏洞#1的攻击影响，然后认识到漏洞#2几乎同样严重（需要少量的权益），但它们是更普遍的。在计划一项协调披露时，我们认为向经济活动不活跃和开发团队不活跃的加密货币披露该漏洞可能会适得其反（例如，风险在于，如果漏洞被泄露，在其他人有时间部署缓解措施之前，它可能会影响其他人）。最终，我们决定将注意力集中到15个最有可能受到攻击的加密货币（前200名的加密货币）。

一个复杂的因素是，这些代码库中的大多数没有使用regtest模式，因此我们不能轻易地演示攻击，也不能为每个代码库提供一个再现性工具包。因此，我们只提供了stratisX的C++代码库演示。基于代码库中的相似性，我们通知了所有我们认为会受到影响的15个团队。其中，有5个团队承认了这一漏洞，有3个团队仍在调查当中，3个团队反驳了这一漏洞（指出其已实施了减轻影响的措施），另外有4个团队没有做出回应。对于没有响应的四个团队，我们通过他们的网站找到的渠道联系他们。这里可以找到我们的Github漏洞再现性工具包，以及关于漏洞#1的简短论文。我们还为漏洞保留了CVE，其应该很快就会被公开。

缓解措施

我们看到有团队针对我们的漏洞披露实施了一系列缓解措施。一些加密货币实现了检测攻击并断开与攻击对等体连接的缓解措施。简单地说，节点监视其对等节点的异常行为（例如，在fork上发送多个区块头）。这种启发式方法的挑战在于，很难区分实际攻击和经历合法重组的诚实节点，因此该方案存在错误禁止诚实节点的风险。到目前为止，我们看到的缓解措施看起来是合理的，但这是一个值得进一步调查的领域。

其他一些加密货币在固定长度范围内添加了部分验证。如果对等方接收到一个从主链分叉超过该长度的区块，那么该区块就被丢弃了。例如，在BCH（比特币现金）的ABC代码库中也采用了这种方法，该代码库使用一个10区块的滚动检查点。这种方法的缺点是它引入了“链分裂”的可能性。当诚实的节点最终位于区块链的不同分叉上时，就会发生链分裂。例如，如果网络连接不良，导致节点彼此失去同步的时间足够长，从而创建冲突的检查点，则可能发生这种情况。即使节点重新获得连接，它们也无法实现链的同步。我们注意到，即使没有这种缓解措施，也存在链分裂的风险。回顾前面的关注点B，由于 coinstake交易是使用当前链中的交易输出进行验证的，因此，如果节点临时发现自己在一个分叉上，则可能无法切换到实际的主链。

链分裂风险也为敌对矿工引入了新的攻击手段。攻击者可以尝试秘密挖取一个长链，然后将其发布到节点的一个子集，以导致链分裂。IBD（初始块下载）中的节点，或长时间离线后刚重启的节点特别易受这种攻击。这种攻击可以与Eclipse攻击结合起来，将诚实的节点引入由攻击者控制的链中。

所有这些缓解措施可使攻击难以执行，但仍然无法替代完全验证。一些加密货币，如量子链，计划在未来版本中全面验证非主链区块。

应建议以下受影响加密货币的用户将其节点更新为最新的补丁软件，需要注意的是，未更新的节点，我们可利用此漏洞导致节点RAM或磁盘消耗增加，并最终导致其崩溃。

下表显示了我们认为受上述两大漏洞影响的加密货币。我们还没有验证所有的PoS币，我们也没有研究那些反驳我们的说法的币种团队为什么没有受到影响。

最后的想法

虽然“伪造权益”攻击在原理上是很简单的，但它们强调了一个困难的设计挑战：在工作量证明（PoW）中有意义的一些想法，不能安全地转换到权益证明（PoS）。考虑到Bitcoin Core作为PoSv3加密货币的“先辈”，它们的代码共享程度是很高的，我们认为这值得进一步审查。在调查这些漏洞时，我们发现了几个针对各种缓解措施和特别防御措施的在建工程代码库。对我们来说，这表明PoS开发者意识到在这一设计空间中的权衡和需求，还没有被完全理解。挑战在于，一方面，我们希望尽快拒绝无效的区块，另一方面，我们不希望陷入链分裂或在处理实际的主链时被延迟。处理这一问题的系统方法，仍然是未来需要探索的工作。

尽管我们看到最近的漏洞例子（例如比特币中的CVE 2018–17144）至少影响了两个加密货币的代码库，但据我们所知，这是第一次跨如此多（20+）独立加密货币的协调安全漏洞披露。考虑到不同加密货币之间思想的交叉传播和代码重用的数量，我们预计将来会有更多这样的漏洞。我们发现，这些代码库的安全过程几乎没有一致性。例如，它们中的大多数没有专门的安全联系人。为协调披露建立最佳实践，可能有益于整个生态系统。

[1]这个漏洞的想法起源于2018年夏季，当时Andrew Miller正在与Unit-E开发人员合作。我们感谢Munto Sunbasz和Gil Danziger的有益讨论和DTR基金会（HTTPS://DTR.OR/）的研究资助。

[2]Emercoin实现了一种启发式对等检测。https://github.com/emergoin/emergoin/commit/ec32762B99cc68fb9ab2909dda96bc7a13bd819

[3] 在Qtum 中的滚动检查点 https://github.com/qtumproject/qtum/commit/8d208d0bee8449c1e4a3904f3fc97ed26156648

[4]PoS的特别检查示例如下：https://github.com/peercoin/peercoin/blob/ebb4003ce8367501020181f7e734d52c4b1ab5ea/src/main.cpp l2564

[5]我们通过电子邮件联系了一些团队，列出了他们的网页或“发送便条”功能。

[6]从11月开始，我们多次尝试通过PIVX网站上的联系方式联系他们，截至撰写这篇文章是，我们才意识到PIVX还启动了一个名为Hacker One的项目，我们注意到，即使到今天，PIVX网站上的bug赏金页面本身，也根本没有提到Hacker One项目。

[**] StratisX已经从脆弱的C++代码库转移到C#代码库。