如何通過工作量證明PoW來模擬容量證明PoC

介紹

容量證明是一種合理、公平的共識(shí)算法。合理是因?yàn)樗褂矛F(xiàn)成的設(shè)備，不浪費(fèi)能源。公平是因?yàn)樗幸粋€(gè)非常低的進(jìn)入壁壘，并顯示了一個(gè)更線性的比例。

從本質(zhì)上講，容量證明包括存儲(chǔ)難以計(jì)算的哈希值，然后在每次偽造塊時(shí)重用這些哈希值。其基本思想是：您擁有的容量越大，可以存儲(chǔ)的哈希值越多，您對系統(tǒng)的承諾就越高，而您的回報(bào)（您構(gòu)建塊的機(jī)會(huì)）也應(yīng)該越高。顯然，如果一個(gè)人能夠通過任何方法偽造容量——例如將其與工作量證明（PoW）相結(jié)合——那么該算法就不再公平，也不再合理。

人們總是可以嘗試使用工作量證明來模擬容量證明，但是要使容量證明保持合理和公平，這種模擬在經(jīng)濟(jì)上是不可行的。然而，盡管PoW的發(fā)展繼續(xù)受到摩爾定律（計(jì)算能力每兩年左右翻一番）的制約，但每Gb存儲(chǔ)的成本并沒有以同樣的速度增長。如果這一趨勢繼續(xù)下去，容量證明算法將需要隨著時(shí)間的推移而更新，或者停止存在。

在這篇文章中，我展示了一種可能的方法來偽造容量證明算法，目前使用在Burstcoin和其他衍生幣。為了簡單起見，這里考慮了稱為PoC1的格式，但是它可以很容易地?cái)U(kuò)展到偽PoC2容量。最后，給出了一種提高每Mb容量比計(jì)算量的簡單建議。這個(gè)建議由一個(gè)硬分叉組成。然而，那些愿意遷移到提議格式的人將有優(yōu)勢，因?yàn)楦袷綄⒄加酶俚目臻g。

容量證明（圖）

本節(jié)的大部分信息和圖像來自burstwiki。我將在這里保持最小的定義，檢查wiki中的術(shù)語和更完整的解釋?？梢杂脕韨卧靿K的預(yù)計(jì)算哈希值存儲(chǔ)在所謂的plot文件中。一個(gè)plot文件包含許多nonces，但是在這里我們可以只關(guān)注一個(gè)nonce。

每個(gè)“nonce”由4096個(gè)不同的scoop組成。每個(gè)scoop包含64字節(jié)的數(shù)據(jù)，包含兩個(gè)哈希值。當(dāng)鍛造一個(gè)塊時(shí)，選擇一個(gè)scoop，礦工應(yīng)該閱讀它的內(nèi)容。每個(gè)scoop內(nèi)部的哈希值應(yīng)該很難實(shí)時(shí)計(jì)算，因此需要預(yù)先計(jì)算它們并有空間存儲(chǔ)它們。計(jì)算這些哈希值的過程如下：

1計(jì)算第一個(gè)哈希值，還是最后一個(gè)哈希值取決于您如何看待它（#8191）：

2. 計(jì)算第二個(gè)哈希值（#8190）：

3.計(jì)算第三個(gè)哈希值（#8189）：

4. 按照相同的過程，預(yù)先將產(chǎn)生的哈希值附加到新種子中，以計(jì)算最多128個(gè)哈希值。

5. 對于所有剩余的迭代，我們只需要128哈希值（最后#4096生成的字節(jié)）：

6. 計(jì)算最后的哈希值，使用所有#8192哈希值和前16個(gè)字節(jié)作為種子：

7. 單獨(dú)列出Xor和所有其他哈希：

8. 有了這一切，我們就有了所有屬于nonce的信息：

這就是所謂的PoC1格式，為了簡單起見，我將避免與這里的PoC2搞混，但又不失一般性。

前面顯示的所有步驟都是為了避免偽造容量。最后一個(gè)哈希（步驟6）包括所有以前計(jì)算的哈希，以確保沒有人可以在不計(jì)算整個(gè)nonce的情況下獲得特定的獨(dú)家信息。

丟棄哈希，根據(jù)需要計(jì)算它們

現(xiàn)在考慮您計(jì)算整個(gè)nonce的情況，但只存儲(chǔ)第6步的最終哈希，不存儲(chǔ)XOR任何哈希（避免步驟7）。然后，讓我們假設(shè)下一個(gè)塊需要4095哈希，這將是非常便宜的實(shí)時(shí)計(jì)算，你不需要它在您的硬盤驅(qū)動(dòng)器上。只需要完成步驟1和步驟2，然后直接跳到步驟7，因?yàn)槟呀?jīng)存儲(chǔ)了最終的哈希。這將是非常便宜的，因?yàn)?8191和#8190哈希使用非常小的種子輸入。計(jì)算scoop 4094需要更多的工作，而且隨著scoop 0的接近，需要的工作也越來越多。

通過只存儲(chǔ)最終哈希，這種方法只對高scoop有效，因?yàn)橛?jì)算低scoop的難度增加了，scoop 0的計(jì)算成本更高。因此，這種方法只允許偽造一小部分空間，要求不誠實(shí)的礦工存儲(chǔ)大部分的scoop號(hào)。

另一種更復(fù)雜的方法是存儲(chǔ)包含128個(gè)散哈希的連續(xù)部分。這樣，您可以丟棄128個(gè)哈希，然后存儲(chǔ)128個(gè)哈希，然后再丟棄，依此類推，保留最后的哈希（步驟6）。每次需要丟棄哈希時(shí)，只需讀取前面的128個(gè)哈希，然后使用步驟5計(jì)算丟失的哈希。這是可能的，因?yàn)槟恍枰懊娴?28個(gè)哈希來計(jì)算一個(gè)新的哈希，而不需要整個(gè)nonce（假設(shè)最后的哈?？捎茫?/p>

一個(gè)簡單的建議，使容量證明更抗PoW

正如上一節(jié)所解釋的，通過動(dòng)態(tài)計(jì)算哈希來偽造容量的一種可能方法是存儲(chǔ)具有128個(gè)哈希的連續(xù)部分并丟棄部分哈希（不存儲(chǔ)它們）。通過一個(gè)簡單的解決方案，這種偽造能力的難度可以大大增加：只有4倍（或2、8、16等）的scoop才能用于鍛造塊。這可以用一行代碼實(shí)現(xiàn)Burstcoin。這個(gè)叉將包含替換掉GeneratorImpl.java的第141行：

假設(shè)選擇步驟4。當(dāng)然，這將是一個(gè)在生產(chǎn)代碼中其他地方定義的常量，并且依賴于塊的高度（fork塊）。

這樣，一個(gè)誠實(shí)的采礦者將只需要存儲(chǔ)當(dāng)前使用空間的25%，并且永遠(yuǎn)不需要存儲(chǔ)連續(xù)的哈希，因?yàn)橹挥羞@部分scoop將用于鍛造塊。試圖偽造容量的數(shù)據(jù)庫需要存儲(chǔ)比誠實(shí)的數(shù)據(jù)庫更多的信息（因?yàn)榭偸切枰?28個(gè)連續(xù)哈希來計(jì)算一個(gè)新的哈希），因此變得不經(jīng)濟(jì)。

挖掘軟件也很容易適應(yīng)只存儲(chǔ)/讀取有效獨(dú)家新聞?？贪鏅C(jī)/清道夫?qū)εc此實(shí)現(xiàn)已在：

https://github.com/jjos2372/engraver

https://github.com/jjos2372/scavenger

這種改進(jìn)型清除劑可以簡單地在改進(jìn)型小區(qū)或規(guī)則小區(qū)中工作。修改后的刻版器還可以生成常規(guī)文件。然而，修改后的刻版器接受一個(gè)額外的參數(shù)，即在存儲(chǔ)情節(jié)時(shí)應(yīng)該跳過或跳過的scoop數(shù)。對于只存儲(chǔ)4的倍數(shù)，這將是：

刻版器- j4［其他論點(diǎn)…］

由此產(chǎn)生的“壓縮”文件名附加了跳過scoop的數(shù)量：

id_start_nonces_nskip

兼容性

使用建議的硬分叉，會(huì)導(dǎo)致現(xiàn)有的文件將繼續(xù)按原樣工作。采礦者可以“壓縮”（僅僅扔掉75%的scoop），然后用新的nonces來繪制剩余的空間。池軟件也可以保持不變（或者更新將是最小的，以防在池軟件中計(jì)算scoop數(shù)）。

目前還沒有一個(gè)“壓縮”工具可用來減少現(xiàn)有圖的大小，但是實(shí)現(xiàn)很簡單，如果這個(gè)建議被接受，就可以使用它。

結(jié)論

容量證明（PoC）總是可以通過工作量證明（PoW）來模擬。然而，為了保持容量證明的合理和公平，偽造能力在經(jīng)濟(jì)上不應(yīng)該是可行的。目前在Burstcoin和其他衍生幣中實(shí)現(xiàn)的容量證明算法目前存在偽容量問題。在這項(xiàng)工作中提出了一個(gè)非常簡單的解決方案，增加了不誠實(shí)礦工的難度。