比特幣 ASIC 是否針對固定長度消息進行了優化？

比特幣區塊頭是 80 字節。

int32_t nVersion;       // 4 bytes
uint256 hashPrevBlock;  // 32 bytes
uint256 hashMerkleRoot; // 32 bytes
uint32_t nTime;         // 4 bytes
uint32_t nBits;         // 4 bytes
uint32_t nNonce;        // 4 bytes
                       // total: 80 bytes

SHA256 ASIC 專門設計用於一遍又一遍地（加倍）散列這些欄位，直到結果值低於由nBits.

由於它是雙重散列，ASIC 必須能夠散列長度為 80 和 32 的初始消息。在 SHA256 所需的填充之後，將被散列的字節串的長度分別為 128 和 64。因此，比特幣 ASIC 顯然必須能夠散列長度為 128 和 64 的消息。

但是假設我的電腦上有一個文件要長得多（長 10,000 倍）。我可以用 SHA256 比特幣 ASIC 對其進行雜湊處理嗎？

它是否因 SHA256-ASIC 和 SHA256-ASIC 的製作方式而異？

比特幣 ASIC 是否針對固定長度消息進行了優化？

如果他們不是，我真的會感到驚訝。如果您可以通過減少可用記憶體量來使您的核心縮小 10%，那麼這很容易。

但是假設我的電腦上有一個文件要長得多（長 10,000 倍）。我可以用 SHA256 比特幣 ASIC 對其進行雜湊處理嗎？

從理論上講，這可能是可能的，但沒有意義。在 ASIC 可以散列您的 800 KB 文件之前，需要將其傳輸到 ASIC。如果 ASIC 有 USB 或乙太網驅動程序，那還不錯，但很多都沒有；使用串口並從 FTDI 購買串口轉 USB 轉換器更便宜。這些介面的最高速率通常為 192 千波特，因此傳輸文件大約需要 33 秒。

但是，大多數 ASIC 都支持“中間狀態”，它表示輸入中散列函式的內部狀態。這樣做的實際結果是，您可以使用 CPU 對文件的前 800 KB 進行雜湊處理，然後使用您的 ASIC 更改文件的最後 4 個字節以搜尋低於目標的隨機數。

最後，我想指出，這些 ASIC 都沒有計算 SHA256。他們正在計算 SHA256d。

引用自：https://bitcoin.stackexchange.com/questions/35399