Re-chained PoSt (Latency model) (better name?)

Assume the Latency model, WinningPoSt-like setting.

Assuming HDD access latency of $\tau = 17 [\textrm{ms}]$

Targeting a percentage $\alpha$ of the block time, perform $N$ iterations of the following routine:

Initial Input: interactive randomness

We can perform $N = \frac{\alpha\cdot\textrm{block time}}{\tau}$ of such iterations while the adversary has $\textrm{block time}$ duration to regenerate $N$ iterations in sequential manner.

We use $M$ challenges in each iteration, to decrease the efficiency of the adversary storing some percentage of replicas.

Given that the adversary has $\textrm{block time}$ to regenerate $N$ sequentially, this gives that we need to ensure that the adversary cannot regenerate faster than:

If sealing takes time $t_H$ and regeneration takes time $t_A$ then the $C_L = \frac{t_H}{t_A}$

Value of $C_L$ in current PoRep is ~240 (120min to seal, 32s to regenerate).

From this we get that:

Adversary can delete $\beta$ percentage of storage (space gap) while caching $1-\beta$ of it on fast device for which we assume access latency of zero.

This result in the adversary having the chance of $1-(1-\beta)^M$of during the iteration incurring latency penalty of $t$ due to being forced to regenerate. $M$ in the range of 20-40 results in very high probabilities of forced regeneration for $\beta$ in range of 0.1-0.2.

Similar to:

Current numbers:

52k challenges, 20ms time to regenerate, M=30,

Instead of using execution extension, we use a natural delay of regeneration.

“it's fine if an adversary can regenerate a single challenge”

2018 conversation: if you are in latency model, you must assume that PoRep is free, so I regenerate all my sectors when I’m challenged.

Way to get around it: High minimum miner size, cost model element