Table of Contents
Decompression - Pool vs Solo
Compressed plots work with a “time-space” tradeoff, removing parts of the plot and recreating them on the fly during farming. This latter part means that whenever a (partial) proof is fetched, additional computational resources will be utilised, compared to the OG uncompressed plots (C0). In this guide, we try to quantify how much extra resources are used for a farmer due to “recomputation”/“decompression” in a pool vis-à-vis if they were farming solo. We make a distinction between
- quality recomputations: passing the plot filter
- proof recomputations: performing a (partial) proof lookup
Note: For simplicity, we use plot size k32 and plot filter 512.
Quality Recomputations
There are 9216 signage points a day. For every signage point, a k32 plot has a 1/512 chance to pass the plot filter. When passing the filter, a quality string lookup needs to be performed. In the case of compressed plots, parts of the plot must be recomputed to complete the quality lookup.
Thus, for every signage point, we expect 1/512 = 0.001953125 recomputations per k32.
Proof Recomputations
When pooling, every k32 is expected to produce 10 points per day on average. Let's look at some examples at various pool difficulties. A single k32, at:
- pool difficulty 1, is expected to submit 10 (partial) proofs per day, worth 1 point each;
- pool difficulty 10, is expected to submit 1 (partial) proof per day, worth 10 points;
- pool difficulty 100, is expected to submit 0.1 (partial) proofs per day, worth 100 points.
In the case of compressed plots, parts of the plot must be recomputed for a (partial) proof.
Thus, with pool difficulty 1, we expect 10 recomputations per 9216 signage points. That's 10/9216 = 0.001085069444 expected recomputations per k32.
Pool vs Solo
Putting quality and proof recomputations together, we see that1:
- A solo farmer is doing 1/512 recomputations per signage point.
- A pool farmer at pool difficulty 1 is doing 1/512 + 10/9216 recomputations per signage point.
That means that the pool farmer is faced with an overhead of ~56% at plot filter 512. And half of that at plot filter 256. This overhead decreases linearly with pool difficulty, so let's have a look at the effect at varying pool difficulties:
| Pool Difficulty | Overhead | |
|---|---|---|
| plot filter 512 | plot filter 256 | |
| 1 | 56% | 28% |
| 5 | 11% | 6% |
| 10 | 6% | 3% |
| 50 | 1% | 0.5% |
| 100 | 0.5% | 0.3% |
| 500 | 0.1% | 0.06% |
[1] For simplicity, we ignore recomputations for actual blocks.
The implication of this is that the computational overhead due to pooling could be said to be directly independent of farm size, although indirectly large farmers generally have a higher pool difficulty.
TIP: When farming compressed plots in a pool, consider increasing your difficulty a bit. e.g. from 3 minutes per partial, to 6 minutes per partial (if you manually set a fixed difficulty) or to 8 minutes per partial if you use our pool-side automatic difficulty adjustment. See https://xchdata.io/diffcalc to choose your optimal difficulty.