on the number of challenges per layer

To seal a sector, miners need to give PoRep after replication. Sealing time is at least the sum time of replication and proof. While for an adversary to repicate a sector temporary, there is no need for him or her to give proof. So the proof time is the shorter the better.

In order to make consensus about the miner’s distinct disk memory and make sure the miner is actually storing customer’s data, it is necessary to make enough challenges for PoRep.

To make consensus, the successful probability of PoRep for a miner saving n% space passing m challenges per layer is less than t. we suppose pips has make sure source data D is right, otherwise we change layers from 10 to 9, the results still apply.(The calculation is straight forward and the structure of ZigZag leads to tighter bounds.)

m\t\n | 20 | 10 | 5 | 2.5 | 1
-- | -- | -- | -- | -- | --
10 | 0.13 | 0.37 | 0.61 | 0.78 | 0.90
20 | 0.018 | 0.13 | 0.37 | 0.61 | 0.82
50 | 0.000041 | 0.0066 | 0.082 | 0.29 | 0.61
100 | 1.7e-9 | 0.000043 | 0.0067 | 0.082 | 0.37
200 | 2.8e-18 | 1.9e-9 | 0.000044 | 0.0067 | 0.14
500 | 1.4e-44 | 1.5e-22 | 1.3e-11 | 0.0000037 | 0.0067
1000 | 1.8e-88 | 2.3e-44 | 1.7e-22 | 1.4e-11 | 0.000045

To make consensus, for example, mabye 10% difference in mining efficiency is acceptable. In that case, the probability for a dishonest miner to pass PoRep saving 10% space with 100 challenges per layers is less than 0.000043. Averagely the miner need to replicate more than 200,000 times before passing PoRep. This will be too tedious for a rational miner to do, and since seal is slow if he or she done’s have enough machines, this will be impossible to finish under given time.

To make sure the miner is actually storing a replica of the source data, it is meaningless to give a lot of challenges(8000 for example) to make sure the miner is honestly. For even if the miner changes one node at some layer during replication, the out-coming replica will be by no means decoded to source data, and the odd for challenging this node is tiny so the miner will pass PoRep mostly. Then the miner changes one single node or 50% of nodes during replication is almost the same for the customer. Also, what if the miner stores the right replica but refuse to give it back to the customer? It is meaningless to make sure the miner storing the right replica, because we can’t do it and even if we can, we can’t make sure the miner will give the data back to the customer.

What’t the conclusion? When we decide the number of challenges at every layer, we only need to consider it form the perspective of making consensus. 100 challenges per layer for 10%-rational replication may be acceptable. The punishment for a miner failing go give back source data(failing to give PoSt or failing or refusing to decode the source data ) should be used to compensate for customers of storing source data according to their size of pieces. The punishment should be composed of at least two parts, fixed collateral and the coins mined by the corresponding sector in proportion.

Start with the probability table and the PoRep/PoSt challenge discussion in this issue. Review the stated assumptions about replication, source-data recovery, and customer compensation, then document a decided challenge count and the resulting protocol or punishment changes as the definition of done.

Written by the indexing model from the issue text.