Closed nicola closed 4 years ago
This may be the most practical way to ship Filecoin 1.0, as it probably allows to avoid aggSNARK, which still hasn't completely converged.
After talking with @lucaniz and @irenegia I think this might require periodic resealing, which might be a big pain to introduce. Otherwise, it's hard to do a rational analysis: The malicious miner tries to seal a incorrect encoding e.g. with many zeroes at the end. There's some probability a that he loses his depost D, but w.p 1-a (when only sealing once) he can mine forever with that seal.. so the expected profit is essentially (1-a) infinity - D a
What is the actual value of a (order of magnitude)?
If I'm understanding, the proposed attack is something like:
As his reward, he gets to mine 'forever' on this bad/free sector.
I think you're proposing that we need periodic resealing to bound the expected value of mining forever on a bad/free sector.
Here's something to consider, which may not be perfect, but might still address the problem. Depending on the actual values of a, D, and the expected value of block rewards per sector over time (which will decrease), the interval at which resealing is necessary for rationality might be very high.
If that turns out to be the case, perhaps we could just punt the issue on the (explicitly stated) assumption that a protocol upgrade at some point will require a one-time resealing of sectors anyway. Although not the most elegant solution, I think that's already a latent possibility. If we're forced to formalize it in order to solve this problem, that may be preferable to being forced to formalize it as a recurring process and to also design and implement the correct process for tracking and enabling it as such now.
At the limit of procrastination, the hypothetical protocol upgrade could just be deployment of the actual periodic resealing protocol — but again, if the rationally necessary period is high enough, we could defer development of the solution until the first one comes due.
None of this will be applicable if the necessary resealing period is short, but my understanding of the grinding attack is that it's not so bad that introduction of penalties per attempt will make it viable as a short term attack. If instead, it's a risk on the timeframe of T=infinite/forever, then maybe it is less pressing and need not block an initial launch solution.
Just to make sure we all agree on the scenario (and other readers can follow):
In order to reply to the challenge with a valid response, the miner must have the data (can also regenerate it - both cases are honest) or must be lucky enough to not be challenged on the "fake" generated part of the sector (1-soundness).
What we had in mind when proposing INTERACTIVEPOREP was to put a very high collateral for which the rewards of behaving maliciously are very high. In other words, we can make this attack arbitrarily expensive.
(Quick note, @arielgabizon will fill the gaps)
If:
Then, we could find a setting where generating a "fake" sector is more costly than the reward one would get in 1-5 years worth of mining that block.
To summarize discussions. Let C be the expected mining revenue from the file after successful sealing in a period of length t (e.g. t=one year , and we assume once a year people must redo offline phase to keep mining with replica; alternatively make assumption we only care about bounding adversary's profits within period of length t). From discussions, it seems we would want to fix t to be something large like one year or 5 years. Assume a=2^{-lambda) is the soundness. Then the cheating miner's expected profit is a C-D (1-a) . Thus we must take the deposit D such that
D>a C/(1-a) ~ a C.
e.g. if lambda=10 the deposit should be ~ 1/1024 of C
A different view on interactive porep is not about small lambda but just saying: Whatever lambda you fix, interactive porep is at least as safe as noninteractive (when both using the same lambda).
Because in the noninteractive case the cost of the adversary A is only the cost of trying different proofs. In the interactive case, even if the adversary has perfect predictability of the challenge given the commitment, they will have the cost of making the same number of attempts. If they don't have perfect predictability, they will have additional cost of lost deposits.
See here for more details https://github.com/filecoin-project/security-analysis/blob/master/seal-analysis.pdf
A particular case where I has potential advantages over NI, is that in NI you can always grind for a small fraction of fake space. Suppose C is the number of challenges to the last layer, (In our usual notation, we take C=-lambda/log(1-delta)~ lambda/delta) Suppose I replace the last d/C fraction of my replica with zeroes, for some d. The probability I will be queried there is (1-d/C)^C~ e^{-d}
so if d is not too large, in the NI setting I can grind 2^d attempts to find a passing proof.
Whereas in the I case, assuming I cannot predict the ticket, I have prob ~e^{-d} of losing the depost
To conflate issues to some degree perhaps with that of the ticket. My opinion is that we should use interactive porep, and stick with the Pedersen hash function rather than a cheaper more experimental hash.
Given the results from #118 (TINYLAMBDA), we can't have a small lambda and non-interactive offline Porep. Can we keep a small lambda and turning PoRep interactive?
If we decide to go for INTERACTIVEPOREP, then: