什么是Verifier's Dilemma验证者困境与Flow怎么解决？

验证者困境Verifier's Dilemma 是最近在研究Flow 时看到的，似乎中文圈比较少讨论这个，因此就来研究一下这是什么？FLow 如何解决与是否有解决？

Verifiers Dilemma 验证者困境

验证者困境的成因是验证人的计算成本导致的攻击机会。现假设有一个合约，合约中有两个矩阵A, B，若任何人可以提出C = A ⨯ B即可获得合约中的钱。

对于提出C 的交易，验证人需要花费大量的时间在验证上。这导致两种可能：

诚实验证人选择验证，此时理性验证人选择不验证，那么理性验证人就获得更多的时间来寻找Nonce。所有验证人都是理性的（选择不验证），那么这笔未验证的交易就会被包含在链中，使提出人具有攻击空间。

在Bitcoin 中，通过制定标准交易格式，使得这类高运算成本的交易无法被网络接受，但也因此限缩了应用空间。在Ethereum 中，则是通过Gas Limit 来避免，但对于攻击者而言，他仍可发起交易并自己处理、打包，使攻击几乎无成本。

总结而言，验证者困境在于验证阶段对交易人是无成本的，由于交易手续费会全额支付给打包区块的矿工，这使得验证人有动机去省略验证，进而产生攻击空间。

为什么加入检查者无助于问题

加入检查者来避免验证人没有实际验证似乎是个可能的解法，这主要来自于奖励机制的问题，攻击者可以调整恶意交易的数量来降低检查者收益的期望值，当检查者数量增加时也会降低收益期望值，但错误侦测率却与检查者数量正相关。

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 奖励机制有关，还没看到那，先停在这。