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

Creator
Kubuxu
Created
Sep 29, 2023 10:21 AM

Assume the Latency model, WinningPoSt-like setting.

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

Targeting a percentage α\alpha of the block time, perform NN iterations of the following routine:

Initial Input: interactive randomness

  1. Based on randomness generate MM (sector, position) tuples which are challenged (assume that we have mechanism not to challenge the same drive in one iteration).
  2. Fold responses to these challenges into the randomness and repeat.

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

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

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

t>block timeNt>block timeα⋅block timeτt>τα\begin{align} t &> \frac{\textrm{block time}}{N} \\ t &> \frac{\textrm{block time}}{\frac{\alpha \cdot \textrm{block time}}{\tau} } \\ t &> \frac{\tau}{\alpha} \end{align}

If sealing takes time tHt_H and regeneration takes time tAt_A then the CL=tHtAC_L = \frac{t_H}{t_A}

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

From this we get that:

tH>t⋅CLtH>τ⋅CLαt_H > t \cdot C_L\\ t_H > \frac{\tau \cdot C_L}{\alpha}

Adversary can delete β\beta percentage of storage (space gap) while caching 1−β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−β)M1-(1-\beta)^Mof during the iteration incurring latency penalty of tt due to being forced to regenerate. MM 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: UntitledUntitled

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