介紹

容量證明是一種合理、公平的共識算法。合理是因為它使用現成的設備，不浪費能源。公平是因為它有一個非常低的進入壁壘，并顯示了一個更線性的比例。

從本質上講，容量證明包括存儲難以計算的哈希值，然后在每次偽造塊時重用這些哈希值。其基本思想是：您擁有的容量越大，可以存儲的哈希值越多，您對系統的承諾就越高，而您的回報（您構建塊的機會）也應該越高。顯然，如果一個人能夠通過任何方法偽造容量——例如將其與工作量證明（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和其他衍生幣中實現的容量證明算法目前存在偽容量問題。在這項工作中提出了一個非常簡單的解決方案，增加了不誠實礦工的難度。