ProgPoW如何抵禦ASIC？開發團隊IfDefElse為你解答

1

問:在以太坊治理方面，你們的立場是什麼？

答：暫無立場，我們覺得許多問題應該留給社區來回答，比如是否或者說何時採用ProgPoW。我們負責提出新的算法，並樂意回答與之相關的技術性問題。

2

問：ProgPoW 從何而來？

答：IfDefElse 是分析和優化PoW 算法的一個小團隊。我們觀察到ETH 社區一再要求使用一種新的PoW 算法，在這種算法中，專業的ASIC 礦機和常規硬件設施比起來，優勢不大。眼看著諸多算法在ASIC 礦機面前不堪一擊，實在令人心痛，每次新的ASIC 礦機問世都會讓整個ETH 社區陷入沮喪。

於是在2018 年春天裡的一天，我們就有了通過修改Ethash 算法，使其達到GPU 挖礦預期效果的想法。初步編輯好該算法後，我們把它放到了GitHub 公共版塊上進行研發和微調。

問：誰對ProgPoW 進行了測評？

答：在一次收集算法使用反饋的過程中，我們幸運地收到了來自以太坊基金會工程師，以太坊核心研發工程師，NVIDIA 工程師和AMD 工程師的反饋郵件。 NVIDIA 和AMD 工程師都對該算法作出了總體正面的評價。

值得一提的是，有兩處算法的更新優化是基於社區成員mbevand 和Schemykh 的評價作出的。

問：AMD 作何反應？

答：AMD 的回應解決了兩大疑慮：

如果用ProgPoW 算法替代Ethash PoW 算法，難道ASIC 礦機廠商就沒辦法迅速研究開源代碼並製造專門ASIC 礦機嗎？

ProgPoW 算法會不會讓GPU 礦工挖以太難上加難？

AMD 一位工程師給出了肯定回答，理論上是可以針對ProgPoW 造新的ASIC 礦機，但這需要製造方有專門的GPU 知識背景，尤其是內存控制器技術。

不僅如此，他們還表達了對緩存（存在本地數據共享和AMD 芯片上的數據）大小的擔憂。

他們在郵件中提到，不論緩存是8KB 還是16KB，AMD 和NVIDIA 在性能上無大差別。但在32KB 和64KB 時就可能會對兩種GPU 廠商架構產生重大影響，在Polaris 和Vega 上也會存在不兼容性。

根據他們的反饋，我們把PROGPOW_CACHE_BYTES的大小設置為16KB 。

5

問：NVIDIA 作何反應？

答：NVIDIA 工程師大體同意我們的方法。他們說，該算法用運算填補了內存訪問間的漏洞，而不是讓GPU 像高貴的內存控制器一樣無所事事地閒置在那。

他們主要的擔憂是，如果算法裡增加太多隨機運算，最後會變成受計算限制，而非受存儲限制。如此一來，為受計算限制算法打造的ASIC 礦機可能會獲得更大的效率和增益。

根據他們的反饋，我們微調了PROGPOW_CNT_CACHE 和PROGPOW_CNT_MATH 以保證該算法對當下大部分GPU 仍保有受存儲限制。

問：如果ProgPoW 是在主迴路上調用模並使用kiss99() 寫法來選擇隨機指令，那麼針對這一算法設計的ASIC 礦機難道不會更加高效嗎？

答：這是第一次查看該算法時常會有的誤區。事實上，在主迴路上模和kiss99() 寫法的調用，是由CPU 計算並以此生成一個隨機程序，然後再由CPU 進行編譯的。 GPU 負責的是執行優化代碼，而這些代碼已經解決了執行何種指令和使用何種混合狀態的問題。

正如Alexey 所言，ProgPoW 每50 個區塊生成一次源代碼。生成程序示例請見：kernel.cu.

我們也將在標準中作進一步說明。

問：為了編譯生成的源代碼，礦工需要安裝AMD 或者NVIDIA軟件開發工具包嗎？

答：不需要。 AMD 和NVIDIA 的驅動中包含OpenCL，DirectX 和Vulkan 編譯器。對於CUDA 來說，二進制內核文件會和小部分軟件開發工具包一起分配。

問：ProgPoW 算法有GPU 架構上的偏好嗎？

答：沒有，ProgPoW 算法的設計初衷就是盡可能地保證公平性。 OpenCL 和CUDA 在執行上並無差異，16KB 大小的緩存在這兩種架構上都能順暢運行。

我們避免了只在一個架構上進行16 位或24 位運算，無論是AMD 編入索引的寄存器文件，還是NVIDIA 的LOP3，所有的操作都得到了跨代體系架構的良好支持。

用ProgPoW 算法的GPU 在挖礦工作負載中的性能也將反映該GPU 的平均遊戲性能。

問：為什麼經過大量修改VBIOS 的GPU，在Ethash 和ProgPoW 之間的速度差反而比預期慢2 倍以上了？

答：ProgPoW 讀取每哈希的內存是Ethash 的兩倍，因此預期哈希率為1/2。我們之前報告的所有調優和样本哈希率（詳見“Results:Hashrate”）都是在以正常頻率運行的GPU 上面完成的。為降低核心頻率而大量修改VBIOS 將會導致礦機運行該算法時受計算限制，而非受存儲限制。

如果用戶需要更換到新算法，VBIOS 的修改與調優將需要重新進行。

問：你們能講講Ethash ASIC 礦機如何比GPU 礦機效率高出兩倍嗎？

Ethash 算法只需執行3 個組件：

高帶寬存儲器（用於DAG 訪問）

FPGA 的數據表明，Keccak 計算所耗費的功率幾乎可以忽略不計。我們估計，在執行Ethash 算法時，大約只有1/2 的GPU 功率花在了內存訪問上。而Ethash ASIC 礦機的Keccak 和計算核心的功率可以忽略不計，其功率主要消耗在內存訪問上，所以GPU 在挖礦效率上還有兩倍的改進空間。

當前Ethash 挖礦硬件快速摘要：

除Titan V，所有數據均來自whattomine.com 和asicminervalue.com。

第一代Ethash ASIC 礦機，比特大陸的Antminer E3 和GPU 礦機相比沒有任何效率上的優勢。這是因為它的DDR3 內存比GPU 礦機的GDDR 內存功耗更高。

據我們所知，尚未發布的Innosilicon A10 ETHMaster 據說在效率上會有更優表現。因為Innosilicon 在該系列礦機上使用了GDDR6 IP 技術，這將使得它的效率可以達到目前最高效挖礦GPU RTX 2070 的兩倍。

問：HBM 的實用性如何？

答：我們最初的算法評估是使用同種內存類型進行同標準比較的。 HBM 功耗低，但價格貴，就顯得不夠實用。舉個例子，帶有HBM 的NVIDIA Titan V 比起A10 ETHMaster，效率上僅遜色一點，但成本高達3,000 美元，明顯沒有實用性。

帶有HBM 的AMD Vega 卡價格倒是合理，但又因為一些原因它的算力只能達到175 KH/s/W。 Vega 效率受何限制我們尚不確定，增加訪問大小能夠明顯改善這一情況（帶寬利用率從61% 提升至75% —詳見“Results:Hashrate”）但Vega 顯卡的功耗仍然過高。我們期待剛剛宣布的雙倍帶寬AMD Radeon VII 顯卡能在效率上有顯著改善。

我們預估HBM 的功率約為GDDR6 的一半，如果使用HBM 製造昂貴的Ethash ASIC 礦機，算力將超1 MH/s/W，這效率大約是市面上常規GPU 的4 倍。

問：ProgPoW ASIC 能有多高效率？

答：ProgPoW 旨在大幅減少專用ASIC 礦機的效率增益。該算法執行需滿足如下組件：

Keccak 容量變小，因此它在GPU 上的功耗也已經可以忽略不計了。這麼一來，ASIC 礦機在降低功耗方面的優勢也將不復存在。

為了執行隨機序列，ProgPoW ASIC 礦機需要執行和GPU 上的計算核心非常相似東西。所有SIMD 的寄存器訪問、數學運算和緩存訪問都需要類似GPU 的運行環境。

沒錯，ProgPoW ASIC ISA 能夠通過精確設計，使之匹配ProgPoW 算法，例如刪除浮點、增加顯式merge() 等操作。然而這種專業化只會提供少量的邊緣效益，而不是數量級的收益增加。

樂觀來說，我們假設精心設計的ProPoW ASIC ISA 可以移除1/4 計算核心功耗。由於GPU 內核在執行ProPoW 時要活躍得多，我們估計內存接口大約消耗GPU 功率的1/3。那麼使用GDDR 的Prop PoW ASIC 礦機相對功耗則為：

1/3 (內存) * 1 + 2/3 (計算) * 3/4 = 5/6

優勢為1.2 倍

若使用HBM，則ProgPoW ASIC 礦機的相對功耗則為：

1/3 (內存) * 1/2 + 2/3 (計算) * 3/4 = 2/3

優勢為1.5 倍

13

問：能在FPGA 上運行ProgPoW 嗎？

答：首先，在FPGA 上運行ProgPoW 存在實際問題。因為隨機程序每12.5 分鐘更改一次，因此需要經常編譯和加載新的比特流。完成此任務的工具和設施基本上不存在。

就算忽略這個問題，ProgPoW 也不能很好的映射到FPGA，FPGA 對於計算密集的算法(如Keccak 或Lyra)行之有效。通過將多個操作封裝到單個時鐘週期中，同時運行多個操作，這些算法可以顯著地提高性能和降低功耗。

ProgPoW 算法循環有許多在序列中交錯的緩存讀取，這極大地減少了可以打包到單個時鐘週期或併行運行的操作。在ProgPoW 算法下，FPGA 的打包操作既降低了挖礦硬件的性能，又增加了信息通道的長度。因為大型的混合狀態（16 lanes * 32 regs * 4 bytes = 2 kilobytes），增加的信息通道長度也成了一個問題。

如果沿每個信息通道階段性地複制此大混合狀態，則會浪費大量電能。當然，我們也可以把混合狀態存儲在寄存器文件中，讓FPGA 的計算核心看起來很像ASIC 或GPU，但那樣做的話， FPGA 的運算效率將顯低於ASIC。

14

問：以上所有問答貌似十分冗長，能簡單做個總結嗎？

答：當然

原文鏈接：

原文鏈接：

原文鏈接：

https://medium.com/@ifdefelse/progpow-faq-6d2dce8b5c8b

原作者: IfDefElse 翻譯&校對:有條魚

本文由礦視界翻譯整理編輯，如需轉載，請標明出處。