I recently started to learn more about Flow and its cryptographical assumptions. I read a medium article of the Pr. Ed Felten from Offchain Labs entitled “How Not to Solve the Verifiers’ Dilemma” (https://medium.com/offchainlabs/how-not-to-solve-the-verifiers-dilemma-e5fb1af49661). tl;dr: SPoCKs are not solving the verifiers dilemma.
Few days after DapperLabs CTO, Dieter Shirley (one of the father of ERC721), answered back with a straightforward fix for SPoCK forgeability (https://medium.com/dapperlabs/incentivizing-correctness-4e35b67239c).
Unfortunately Pr. Ed Felten, responded that this fix wasn’t enough and that Flow system still suffers from bad equilibria. He wrote that I’ll explain why in a subsequent post (https://medium.com/offchainlabs/flow-is-still-flawed-9363587e50e6). I couldn’t find this last article…
Did anyone know how all this ended ? SPoCKs strong enough or not ?
After reading posts and technical papers once again. my opinion: TLDR; SPoCKs are strong enough.
I think there is a misunderstanding on many levels.
I don’t think bad equilibria possible here, you can always be lazy ( as in example ) counteracted by the risk that you can be slashed. In the end you are betting with the amount staked that the result is correct.
There is no difference between running 1 verifier with 1000 staked vs 10 verifier ( 1 calculating 9 sharing result of verification) with 100 staked. Only game theory area here is minimum required stake to run a node.
To be honest I didn’t totally get @dete’s answer of spoofing SPoCKs. For me as long as messaging layer signs the message coming from Alice, it shouldn’t matter if SPoCK is made for Bob. It should be rejected anyway. ( and even spoofer can be slashed )
I had some email exchanges with Ed after the public exchanges, and I think I can summarize his final objection. The crux comes down to the nature of the confidential knowledge (CK). In our application of SPoCKs in Flow, the CK is a side effect of executing the transactions properly. For example, you could hash together the contents of all data read from or written to storage as part of the transaction.
Our claim is that a lazy or malicious VN can’t produce the same SPoCK as another node because it can’t “guess” the contents of the CK without executing the transaction.
Dr. Felton’s objection is that we don’t have a formal proof that this confidential knowledge is unguessable. In fact, you could say the exact opposite is the case: We provide each VN with exactly the data needed to determine the SPoCK correctly. That’s the point, we WANT the VN to generate the CK!
SPoCKs are used in Flow to prevent shortcuts. You could imagine some theoretical algorithm that could predict the correct SPoCK for a set of transactions without actually executing those transactions. But it’s neigh inconceivable to think that this algorithm would be cheaper than just doing the job we want the VN to do in the first place: Run the code.
You could imagine some theoretical algorithm that could predict the correct SPoCK for a set of transactions without actually executing those transactions.
Given that there is a chance to guess CK without calculating ( let’s say an oracle guessing 99% of the time true ), still I don’t see bad equilibria. Maybe I am missing something,
For me even if I have access to oracle, even it is 99% true, given there are other VNs with sufficient number, chance to cheat drops really fast.
Considering SPoCK as a cryptographic scheme, we have worked on updating the implementation sketched in Technical Paper 3 into a more robust one (although the original construction works with extra authentication). We formalized the new construction and its security proof in a paper some time ago, and it recently became available here: Specialized Proof of Confidential Knowledge (SPoCK).
This is the construction currently implemented in the Flow code base.