一种使容量证明更抗工作量证明的方案

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和其他衍生币中实现的容量证明算法目前存在伪容量问题。在这项工作中提出了一个非常简单的解决方案，增加了不诚实矿工的难度。

—-

编译者/作者：不详

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。