驗證者困境 Verifier’s Dilemma 是最近在研究 Flow 時看到的，似乎中文圈比較少討論這個，因此就來研究一下這是什麼？FLow 如何解決與是否有解決？
Verifiers Dilemma 驗證者困境
驗證者困境的成因是驗證人的計算成本導致的攻擊機會。
現假設有一個合約，合約中有兩個矩陣 A, B，若任何人可以提出 C = A ⨯ B 即可獲得合約中的錢。
對於提出 C 的交易，驗證人需要花費大量的時間在驗證上。這導致兩種可能：
- 誠實驗證人選擇驗證，此時理性驗證人選擇不驗證，那麼理性驗證人就獲得更多的時間來尋找 Nonce。
- 所有驗證人都是理性的（選擇不驗證），那麼這筆未驗證的交易就會被包含在鏈中，使提出人具有攻擊空間。
在 Bitcoin 中，通過制定標準交易格式，使得這類高運算成本的交易無法被網路接受，但也因此限縮了應用空間。在 Ethereum 中，則是通過 Gas Limit 來避免，但對於攻擊者而言，他仍可發起交易並自己處理、打包，使攻擊幾乎無成本。
總結而言，驗證者困境在於驗證階段對交易人是無成本的，由於交易手續費會全額支付給打包區塊的礦工，這使得驗證人有動機去省略驗證，進而產生攻擊空間。
為什麼加入檢查者無助於問題
加入檢查者來避免驗證人沒有實際驗證似乎是個可能的解法，但在 Offchain Labs 的文章中說明並無助於解決。這主要來自於獎勵機制的問題，攻擊者可以調整惡意交易的數量來降低檢查者收益的期望值，當檢查者數量增加時也會降低收益期望值，但錯誤偵測率卻與檢查者數量正相關。
Flow 如何做
Flow 設計了 SPoCK (Specialized Proof of Confidential Knowledge)，流程如下：
- Execution Node 執行交易，產生交易後狀態的同時也產生一個秘密，並發布從這個秘密產生的 SPoCK。秘密來源可能是交易過程中的狀態（例如 CPU Registry 狀態的 Hash），因此可以通過執行交易來取得這個秘密。
- Verifier Node 也執行交易，並同樣產生秘密。
- 觀察者可以檢查兩方產生的 SPoCK 是否源自於相同秘密，並假設 Execution Node 是誠實的，若檢查通過，則相信 Execution Node 不是直接承認交易。
在上述流程中，無法避免 Execution Node 與 Verifier Node 共謀的狀況。之所以假設 Execution Node 誠實的原因是若其提出錯誤的無效的 SPoCK，他將會受到 Slash。
對於一筆交易，必須取得絕大多數 Verifier Node 肯定才能被確認，若是一筆錯誤交易被 Execution Node 提出，並一部分 Verifier Node 肯定，則當有 Verifier Node 否定時，他將可以獲得前面幾個 Node 的獎勵，前面的 Node 也將被 Slash。
寫在最後
看了幾篇，不太敢說全部了解了，但應該也勉強懂一點。Offchain Labs 也寫了幾篇文討論 SPoCK 與 Flow 獎勵機制的可行性與問題，有興趣者可在 Reference 的 4 ~ 6 找到。就我看來，Flow 假設了多數的 Verifier Node 不會與 Execution Node 共謀（SPoCK），這點應該是可以相信的。其他問題和 Flow 獎勵機制有關，還沒看到那，先停在這。
Reference
- Luu, Loi, et al. "Demystifying incentives in the consensus computer"
- Hentschel, Alexander, et al. "Flow: Separating Consensus and Compute–Execution Verification."
- The Cheater Checking Problem: Why the Verifier’s Dilemma is Harder Than You Think
- How Not to Solve the Verifiers’ Dilemma
- Incentivizing Correctness
- Flow is Still Flawed