LeoWe typically think of fixed sector sizes. But let’s flip the question. Suppose someone wants to seal X amount of data, with X much bigger than sector size. What is the right sector size, assuming the graph stays the same, just rescaled, and the security goals remain the same? Here are the considerations I can think of.
Sealing Cost:
PC1 (graph pebbling): should be independent of sector size
PC2 (Merkle tree): a tiny dependence on sector size, because the tree gets slightly deeper as sectors grow; probably insignificant
C1 (choosing challenges with leaves to open): too small to worry about
C2 (opening challenges via SNARKs): the number of challenges is inversely proportional to sector size, because you need a fixed number of challenges per sector to guarantee a particular delta in every sector, so fewer sectors = fewer challenges. However, larger sectors mean slightly longer Merkle paths, because graphs are bigger, but that effect is relatively small compared to the effect on the number of challenges. So larger sectors are better.
Sealing latency:
PC1 (graph pebbling): if PC1 is parallelizible (which it might if we are in the cost model, but probably not if we are in the latency model), then should be independent of sector size. Else, increases with sector size, so smaller sectors are better
PC2 (Merkle tree): Merkle tree is parallelizible, so should not be affected
C1 (choosing challenges with leaves to open): too small to worry about
C2 (opening challenges via SNARKs): Larger sectors are better for the same reason as sealing cost
Unsealing Cost for All of X: should be independent of sector size, because it’s just PC1
Unsealing Cost for a portion of X: Need to unseal only the sectors that are relevant to the portion, so smaller sectors are better
Unsealing Latency: if PC1 is parallelizible (which it might if we are in the cost model, but probably not if we are in the latency model), then should be independent of sector size. Else, increases with sector size. So smaller sectors are better
WinningPoST (i.e., execution in the latency model): Suppose the adversary wants to save more than space gap on at least a constant fraction of the sectors. If execution catches even one of those, the adversary will fail. Thus, execution needs to probe only a constant number of sectors, regardless of their size (unless they are so large that you probe them all). Larger sectors mean higher latency, so we can allow the verifier to wait more time to respond, so larger sectors are better, but the effect is only on the time allowed for PoST.
WindowPoST (i.e., execution in the cost model): Suppose the adversary wants to save more than space gap on at least a constant fraction of the sectors. The adversary’s expected cost is proportional to the number of sectors that are caught. Each sector requires a constant number of queries to catch, so larger sectors are better, as they reduce the total number of queries for a given cost.
Which of these costs scale with X?
Most costs scale more-or-less linearly with X. However,
- if we grow sector size as X increases, then C2 grows only logarithmically
- regardless of the sector size, WinningPoST stays the same
- WindowPoST may improve by some significant constant factor if we can make the following argument (which is made in NSE): the rational adversary will have each sector either fully in memory (except perhaps the spacegap) or not at all, and therefore it suffices to ask just one query per sector (instead of a constant number of queries per sector). This argument seems to require some tradeoff between storage and the probability of being caught after queries; it’s probably worth exploring how it generalizes outside of NSE.