我們可以檢查礦工是否驗證了解決方案嗎？
當礦工找到該塊的解決方案並將其廣播到另一個節點時，所有其他節點都會驗證它是否是正確的解決方案。這個想法在我腦海中彈出了幾個問題：
- 我在某處讀到，如果礦池找到了解決方案，那麼該礦池中的同行礦工不會驗證該解決方案，而是直接在其之上探勘下一個區塊。這對其他礦工來說有點不公平。我們是否有任何系統來檢查礦工是否驗證了解決方案？
- 另一方面，不確定網路上這種情況發生的頻率，但礦工池可以共享錯誤的解決方案，以保持其他礦工忙碌並獲得優勢。這種情況會發生在網路上嗎？
先感謝您！:)
首先，如果我錯了，請糾正我。
當礦工找到該塊的解決方案並將其廣播到另一個節點時，所有其他節點都會驗證它是否是正確的解決方案。
驗證 PoW 非常簡單，只需對塊頭進行雜湊處理，然後計算雜湊包含多少個“前導零”（請注意，這樣的描述是理論上的。允許“分數前導零”的實際實現有些複雜甚至奇怪）。
驗證整個塊比僅驗證標頭要復雜得多且“成本高”。CVE-2018-17144 通貨膨脹/DoS 漏洞實際上是由於驗證程式碼優化不當造成的，以進一步改善區塊傳播。
然而，理論上，無論礦池中有多少礦工，它們只是比特幣 P2P 網路中的一個完整節點（作為礦池的身份）。
建構要開采的區塊的是礦池。使用 Stratum 協議的礦工根本不會下載完整的區塊數據。他們只下載進行 SHA256d 探勘所需的最少數據（如區塊頭、coinbase 交易等）。因此，他們不驗證該塊，因為它甚至根本沒有下載。
所以我們可以看到，目前池化的礦工（他們不執行自己的全節點）盲目地跟隨池，這樣一個邪惡的池運營商就有可能濫用該池中礦工提供的雜湊算力。實際上，一些礦工甚至對這種情況感到滿意，因為一些礦池提倡“自動切換以獲得最大利潤”等功能。如果 BetterHash/StratumV2 協議能夠被廣泛採用，我們將來可能會看到這個問題的改進/緩解。
此外，池礦工確實可以通過扣留解決方案來攻擊池（或池中的其他礦工，具體取決於池的支付模式、PPS 或其他），儘管池驗證解決方案（PoW）非常簡單。
我們可以檢查礦工是否驗證了解決方案嗎？
據我所知，目前無法知道礦工（礦池）是否驗證了整個區塊。
自己再次完全驗證前一個區塊只是礦工自己的利益，這樣他們就完全有信心不會將他們的算力/電力成本浪費在區塊鏈的無效分支上。
我在某處讀到，如果礦池找到了解決方案，那麼該礦池中的同行礦工不會驗證該解決方案，而是直接在其之上探勘下一個區塊。這對其他礦工來說有點不公平。我們是否有任何系統來檢查礦工是否驗證了解決方案？
您似乎描述了一種稱為“SPV 探勘”的無驗證探勘。
但是，它不是“該礦池中的對等礦工”，而是其他礦池（或獨立礦工）可以做到這一點。
它確實曾經引起過一些問題，比如2015 年與 BIP66 相關的鏈分叉事件。
從理論上講，還有一種自私挖礦攻擊的變體，稱為“區塊鏈拒絕服務（BDoS）”，旨在將受害礦工推向盈利線。
還有一個有爭議的論點是，SegWit 也存在類似於 BDoS 的問題，因為開發人員曾經指出，SegWit 允許礦工在不下載和驗證見證數據的情況下在前一個區塊上進行挖礦（主要是數字簽名，只有 SegWit 交易有這樣的數據） ，以便礦工可以更有信心地收取交易費用（因為，對於前一個區塊的非見證部分，它已經足以更新 UTXO 集，這是每個完整的比特幣維護的“全球賬戶餘額數據庫”節點自己）。
另一方面，不確定網路上這種情況發生的頻率，但礦工池可以共享錯誤的解決方案，以保持其他礦工忙碌並獲得優勢。
在自私挖礦中，共享並不是真正的“錯誤”解決方案，而是區塊鏈的陳舊分支，受害者“誠實”礦工別無選擇，只能在其上開採，因為較長的分支被“自私”礦工扣留。
我在某處讀到，如果礦池找到了解決方案，那麼該礦池中的同行礦工不會驗證該解決方案，而是直接在其之上探勘下一個區塊。這對其他礦工來說有點不公平。我們是否有任何系統來檢查礦工是否驗證了解決方案？
礦工將有效區塊送出給礦池運營商，礦池運營商將檢查其有效性。這種檢查計算成本低且執行速度快，因此礦池運營商可以非常快速地決定是否指示礦池參與者在下一個區塊開始探勘。
其他礦池參與者隱含地信任礦池運營商，因此他們會效仿。如果這些礦工正在執行節點，那麼他們的節點將在收到新區塊時對其進行驗證，但這不會影響他們的挖礦操作。
另一方面，不確定網路上這種情況發生的頻率，但礦工池可以共享錯誤的解決方案，以保持其他礦工忙碌並獲得優勢。這種情況會發生在網路上嗎？
任何人都可以發布一個無效塊，事實上這句話本身就是一個無效塊，如果你願意這樣考慮的話。
像上面一樣，確定一個塊是否有效是一種非常便宜且快速的計算，因此任何接收到此類數據的節點都會很快將其丟棄。如果它繼續接收垃圾數據，該對等點最終將被丟棄。
請注意，當新區塊正在驗證過程中時，礦工仍將在目前區塊上進行挖礦。只有當新區塊數據被確定為有效時，礦工（或礦池）才會開始處理下一個區塊。因此，發送無效塊數據不會中斷礦工的操作。