作者：Conflux中文社区 / 来源：投稿

　　本文为Decentralized Systems Lab发表的讨论使用最长链规则的PoS系统安全性的文章。按照某种划分方法，PoS系统可以分为链式结构型(chain-based)和拜占庭容错型(BFT-Style);文章所阐述的漏洞是链式结构型系统中出现的，因此跟Cosmos的Tendermint这样的拜占庭容错型PoS共识算法无关;Casper不使用最长链规则，而是LatestMessageDrivenGhost，因此也跟这里讲的漏洞无关。

　　这些漏洞已经影响了超过 26 类 PoS 型加密货币。通过这些漏洞，一个攻击者只需使用少量权益就能摧毁任何运行相关软件的网络节点。

　　在这次公开披露之前，我们从 2018 年 10 月开始有规划地通知受影响的加密货币开发团队。大部分团队(根据市值计算)已经部署了应对措施。

　　权益证明(PoS)类加密货币，特别是那些基于链上PoSv3(第三版权益证明)的加密货币，它们与比特币很相似，都使用未花费的交易输出(UTXO)模型和最长链共识规则。

　　主要的区别在于前者用Token的所有权证明替代了工作量证明(PoW)。

　　PoS 的潜在优点包括能够降低对环境的影响以及增强对 51% 攻击的抵抗性。

　　很多加密货币实际上是比特币代码库的分叉(至少是衍生物)并且加入了 PoS 的功能。

　　但是，由于它们盲目复製了比特币的一些设计理念，留下了安全隐患，因此出现了一些在原先代码库中并不存在的新漏洞。

　　我们将这些漏洞称为「虚假权益」攻击。

　　从本质上讲，该攻击之所以有效是因为 PoSv3 的程序在签发珍贵资源(硬盘和内存)之前对网络数据验证不足。

　　因此，一个攻击者只需使用很少的权益份额(在某些情况下甚至是零份额)，就能用虚假数据填满某个节点的硬盘和内存，致使其崩溃。

　　我们认为所有基于 UTXO 和最长链原则的权益证明模型都容易受到这类「虚假权益」攻击的影响。经过调查研究，我们已经发现了一批存在漏洞的加密货币，并在文末附上了列表。

　　接下来，我们将详细解释这些漏洞和攻击手法，因为它们会产生一些不易察觉的后果。

　　虽然事后看来这些漏洞本身很简单，但是想要一劳永逸地解决它们还是很困难，而且现有的解决方案可能会导致分叉(后文会给出解释)。

　　背景

　　在深入瞭解这些漏洞的细节之前，我们将简要介绍一些关于链上 PoS 机制原理的背景知识。

　　权益证明挖矿

　　与 PoW 挖矿类似，PoS 挖矿也要将区块头的哈希值(hash)与难度目标进行比较。

　　PoS 的目标是确保每个权益者挖出下一个区块的概率与他们质押的Token量成正比。

　　为了达成这一目标，链式结构型 PoS 机制的哈希值不仅取决于区块头，还取决于权益所有者通过区块中一笔特殊的 「coinstake」 交易平台质押的Token数量。

　　本文会涉及一些关于 PoS 挖矿的具体细节，更详细的解释可以在 Earlz 的博客中找到。

　　本文重点从 1) coinstake 交易和 2) coinstake 交易平台花费的 UTXO 这两方面来阐述 PoS 机制。

　　工作量证明在节约区块验证资源方面起到的作用

　　众所周知，PoW 在比特币共识机制中扮演至关重要的作用，不过它还有一个不那么受重视的作用，就是控制对节点有限资源的访问，例如磁盘、带宽、内存和 CPU。

　　在免许可型公链网络中，一个节点是不能信任其它对等节点的。

　　因此，为了防止资源耗竭型攻击，比特币节点要先检查区块的工作量证明，再决定是否花费更多硬盘或内存资源存储这个区块。

　　但是，事实表明，检查权益证明比起验证工作量证明要复杂的多，对环境也更为敏感。

　　因此，许多链式结构 PoS 机制在有效验证上投入的资源严重不足。

　　为了理解资源耗竭型漏洞产生的原因，我们必须详细说明一下区块在被验证之前是如何存储的。

　　一个节点不仅要追踪当前时刻最长的链，还要追踪一整棵分叉链树(因为任何一条分叉链都有可能成为最长链，在这种情况下，节点需要 「重组」才能切换到新的最长链上)。

　　举例来说，不当升级、双花攻击(例如：遭受 51% 攻击的ETC)，或者临时网络分区都有可能引发这种情况。

　　验证这些非主链上的区块是非常困难的。

　　要完全验证某个区块，你需要上一个区块中未花费的Token(UTXOs)集合。

　　比特币保存的是最长链顶端区块时候的 UTXO 集合，但是不会保存之前区块时候的 UTXO 集合状态(儘管在此前任何一个区块上都有可能形成分叉)。在完全验证分叉链上的区块主要有两种方法：

　　1、将当前视图(UTXO 集合)「回滚」 到分叉起始点之前

　　2、存储之前每一区块时候的 UTXO 状态

　　*校对注：(在 UTXO 模型的区块链中)将一条链上的所有区块所包含的交易都处理完之后就会形成一个 UTXO 的集合，这个集合就是该链的最新状态。因此，哪怕在同一条链上， #100 区块时候的状态(UTXO 集合)与 #101 区块时候的状态也是不同的。上文的意思是，虽然每一个区块上都有可能形成分叉，但比特币软件不会把每一个区块时候的状态都专门保存一个副本，而是只保存最新的 UTXO 集合;若是每一个区块时候的状态都要专门保存，这会变成很大一笔存储开销。

　　比特币的代码库不支持第二个方法，即使它支持，这也会增加额外的存储成本(比特币的节点性能依赖于大幅裁减不必要的数据)。

　　比特币代码库目前正是採用第一种方法来处理重组的。

　　然而，经常回滚的代价也是很昂贵的，因此，回滚和完全验证不会在一有分叉的时候就发生，而是等到分叉链上的工作量证明真的超过当前主链的时候才会进行。

　　因此，当一个对等节点第一次接收到一个非最长链上的区块或区块头时，我们将跳过完全验证并将这个区块保存在本地存储区。

　　在将这个区块存储进磁盘之前，比特币代码库会基于 PoW 机制执行一些初步验证(不过会忽略区块内的交易)。

　　初步验证仅针对之前的区块头以及当前的区块头，因此节点验证起来非常快。而且这是一个非常有效的防御手段，因为生成一个有效的工作量证明来通过这个初步验证成本很高。

　　例如，虽然有可能欺骗一个比特币节点将一个非法区块存储在硬盘内，但是以这种方式发起资源耗竭型攻击是一个非常不经济的行为。

　　PoS 机制中也存在类似的初步验证过程，就是对 coinstake 交易进行验证，将它与上一个区块的 kernel 值一起进行哈希运算，看最后得到的哈希值是否超过难度目标。

　　计算 coinstake 交易的哈希值很容易，难的是验证 coinstake 交易中输入的 UTXO 是否合法并且未被花费;但是要检查一笔 UTXO 是否没有被花费，你就需要该笔交易发生前一个区块时候的 UTXO 集合状态;如我们上文所说，节点往往是没有专门存储这样一个状态的。

　　因为完全验证 coinstake 交易是非常困难的，大多数链上 PoS 机制提供的是一个经验式或者近似式的验证方法作为替代。

　　事实证明这些替代性的验证方法通常并不充分并且存在漏洞。

　　漏洞：「我简直不敢相信还有非权益持有者可以攻击的漏洞」

　　我们第一次研究这个漏洞的时候，发现Qtum、Particl、Navcoin、HTMLcoin 和Emercoin这五种密码学货币都存在这个漏洞，即，在将区块提交至内存或硬盘之前，无法对 coinstake 交易进行验证。

　　这五种加密货币的共同之处是它们都採用了比特币的「区块头优先」 规则，将区块分成两类独立的信息——区块体和区块头——进行传播。

　　只有当节点确认了某个区块的区块头通过了 PoW 验证、并且该区块跟在最长链(或更长链)之后，才会请求区块体的信息。

　　由于 coinstake 交易仅存在于区块体而非区块头中，节点无法做到只验证区块头，于是直接将区块头存储在了内部数据结构(mapBlockIndex)里。

　　因此，任何网络攻击者，即使不持有任何权益，也可以恶意填满一个节点的内存。

　　此种攻击的还有另一个形式，可以针对相同的代码库实施，不过它採用的方式略微不同，而且攻击目标也从节点的内存资源转向了硬盘资源。

　　可以说，针对节点硬盘的攻击危害更大：如果节点因内存被填满而崩溃，只需简单重启即可恢復。

　　但是，如果硬盘被填满了，则需要手动干预才能恢復(例如，运行一个外部脚本来清除硬盘中的过时区块)。

　　如果接收的不是区块头而是区块体，需要执行初步验证也会不同。理想情况下，因为 coinstake 交易就包含在区块体中，节点软件应该先对其进行验证，再将区块体提交至硬盘。

　　但是，如上所述，如果这个区块是在一条分叉链上，节点要访问 coinstake 交易平台花费的 UTXO 会难得多。也许是出于这个原因，这些代码库并没有验证 coinstake 交易。

　　对于存在上述任意一个漏洞的加密货币来说，即使是不持有任何权益的人也能对它们发动攻击。

　　针对内存的资源耗竭型攻击微不足道，从技术的角度来看，我们更需要堤防的是针对硬盘的资源耗竭型攻击(儘管二者都是不需要持有任何权益就能发动的攻击)。