如何通过工作量证明PoW来模拟容量证明PoC

介绍

容量证明是一种合理、公平的共识算法。合理是因为它使用现成的设备，不浪费能源。公平是因为它有一个非常低的进入壁垒，并显示了一个更线性的比例。

从本质上讲，容量证明包括存储难以计算的哈希值，然后在每次伪造块时重用这些哈希值。其基本思想是：您拥有的容量越大，可以存储的哈希值越多，您对系统的承诺就越高，而您的回报（您构建块的机会）也应该越高。显然，如果一个人能够通过任何方法伪造容量——例如将其与工作量证明（PoW）相结合——那么该算法就不再公平，也不再合理。

人们总是可以尝试使用工作量证明来模拟容量证明，但是要使容量证明保持合理和公平，这种模拟在经济上是不可行的。然而，尽管PoW的发展继续受到摩尔定律（计算能力每两年左右翻一番）的制约，但每Gb存储的成本并没有以同样的速度增长。如果这一趋势继续下去，容量证明算法将需要随着时间的推移而更新，或者停止存在。

在这篇文章中，我展示了一种可能的方法来伪造容量证明算法，目前使用在Burstcoin和其他衍生币。为了简单起见，这里考虑了称为PoC1的格式，但是它可以很容易地扩展到伪PoC2容量。最后，给出了一种提高每Mb容量比计算量的简单建议。这个建议由一个硬分叉组成。然而，那些愿意迁移到提议格式的人将有优势，因为格式将占用更少的空间。

容量证明（图）

本节的大部分信息和图像来自burstwiki。我将在这里保持最小的定义，检查wiki中的术语和更完整的解释。可以用来伪造块的预计算哈希值存储在所谓的plot文件中。一个plot文件包含许多nonces，但是在这里我们可以只关注一个nonce。

每个“nonce”由4096个不同的scoop组成。每个scoop包含64字节的数据，包含两个哈希值。当锻造一个块时，选择一个scoop，矿工应该阅读它的内容。每个scoop内部的哈希值应该很难实时计算，因此需要预先计算它们并有空间存储它们。计算这些哈希值的过程如下：

1计算第一个哈希值，还是最后一个哈希值取决于您如何看待它（#8191）：

2. 计算第二个哈希值（#8190）：

3.计算第三个哈希值（#8189）：

4. 按照相同的过程，预先将产生的哈希值附加到新种子中，以计算最多128个哈希值。

5. 对于所有剩余的迭代，我们只需要128哈希值（最后#4096生成的字节）：

6. 计算最后的哈希值，使用所有#8192哈希值和前16个字节作为种子：

7. 单独列出Xor和所有其他哈希：

8. 有了这一切，我们就有了所有属于nonce的信息：

这就是所谓的PoC1格式，为了简单起见，我将避免与这里的PoC2搞混，但又不失一般性。

前面显示的所有步骤都是为了避免伪造容量。最后一个哈希（步骤6）包括所有以前计算的哈希，以确保没有人可以在不计算整个nonce的情况下获得特定的独家信息。

丢弃哈希，根据需要计算它们

现在考虑您计算整个nonce的情况，但只存储第6步的最终哈希，不存储XOR任何哈希（避免步骤7）。然后，让我们假设下一个块需要4095哈希，这将是非常便宜的实时计算，你不需要它在您的硬盘驱动器上。只需要完成步骤1和步骤2，然后直接跳到步骤7，因为您已经存储了最终的哈希。这将是非常便宜的，因为#8191和#8190哈希使用非常小的种子输入。计算scoop 4094需要更多的工作，而且随着scoop 0的接近，需要的工作也越来越多。

通过只存储最终哈希，这种方法只对高scoop有效，因为计算低scoop的难度增加了，scoop 0的计算成本更高。因此，这种方法只允许伪造一小部分空间，要求不诚实的矿工存储大部分的scoop号。

另一种更复杂的方法是存储包含128个散哈希的连续部分。这样，您可以丢弃128个哈希，然后存储128个哈希，然后再丢弃，依此类推，保留最后的哈希（步骤6）。每次需要丢弃哈希时，只需读取前面的128个哈希，然后使用步骤5计算丢失的哈希。这是可能的，因为您只需要前面的128个哈希来计算一个新的哈希，而不需要整个nonce（假设最后的哈希可用）。

一个简单的建议，使容量证明更抗PoW

正如上一节所解释的，通过动态计算哈希来伪造容量的一种可能方法是存储具有128个哈希的连续部分并丢弃部分哈希（不存储它们）。通过一个简单的解决方案，这种伪造能力的难度可以大大增加：只有4倍（或2、8、16等）的scoop才能用于锻造块。这可以用一行代码实现Burstcoin。这个叉将包含替换掉GeneratorImpl.java的第141行：

假设选择步骤4。当然，这将是一个在生产代码中其他地方定义的常量，并且依赖于块的高度（fork块）。

这样，一个诚实的采矿者将只需要存储当前使用空间的25%，并且永远不需要存储连续的哈希，因为只有这部分scoop将用于锻造块。试图伪造容量的数据库需要存储比诚实的数据库更多的信息（因为总是需要128个连续哈希来计算一个新的哈希），因此变得不经济。

挖掘软件也很容易适应只存储/读取有效独家新闻。刻版机/清道夫对与此实现已在：

https://github.com/jjos2372/engraver

https://github.com/jjos2372/scavenger

这种改进型清除剂可以简单地在改进型小区或规则小区中工作。修改后的刻版器还可以生成常规文件。然而，修改后的刻版器接受一个额外的参数，即在存储情节时应该跳过或跳过的scoop数。对于只存储4的倍数，这将是：

刻版器- j4［其他论点…］

由此产生的“压缩”文件名附加了跳过scoop的数量：

id_start_nonces_nskip

兼容性

使用建议的硬分叉，会导致现有的文件将继续按原样工作。采矿者可以“压缩”（仅仅扔掉75%的scoop），然后用新的nonces来绘制剩余的空间。池软件也可以保持不变（或者更新将是最小的，以防在池软件中计算scoop数）。

目前还没有一个“压缩”工具可用来减少现有图的大小，但是实现很简单，如果这个建议被接受，就可以使用它。

结论

容量证明（PoC）总是可以通过工作量证明（PoW）来模拟。然而，为了保持容量证明的合理和公平，伪造能力在经济上不应该是可行的。目前在Burstcoin和其他衍生币中实现的容量证明算法目前存在伪容量问题。在这项工作中提出了一个非常简单的解决方案，增加了不诚实矿工的难度。