I have scraped space pledged to Gemini 3g since genesis based on the block challenge solution range. The x-axis is in blocks and y-axis is in terabytes.
The ladder-like structure is due to the solution range adjustment mechanism: the solution range (and thus the pledged space estimate) stays constant for 2016 blocks and adjusts based on the block production rate.
As expected, it is steadily increasing except for the previous ~36 hours drop. I attribute this to many sectors having to replot at that point (bearing witness my own farmer). Since the history is relatively short, each newly archived segment may trigger the replotting of many sectors. As we can see, the space pledged started going up again in the last few hours, meaning replottings have been completed.
Here’s the same graphic in scale of days rather than blocks on the x-axis:
It seems that replotting starts just before block 100,000. What is the earliest block number in which a sector can expire?
Do you know how long it takes to:
plot a single sector on a typical machine?
gather all the required records for a sector?
Additionally, there was a suggestion to start replotting even before the sector expires, such that the farmer has a new sector ready when the original one expires (this will require the farmer to temporarily allocate extra disk space to Subspace). Is this something currently being considered?
Replotting algorithm has no dependence on block number whatsoever. That impression is given only by the way the chart is build since we track solution range (and thus space pledged) in block headers and it is updated every 2016 blocks (thus the ladder structure). The actual attribution of the dip to replotting is a little more complex than in my original post: the dip shows that the solution range was increased, because blocks were produced less frequently, because less space was farming. And it is the latter I attribute to replotting.
start replotting even before the sector expires, such that the farmer has a new sector ready when the original one expires (this will require the farmer to temporarily allocate extra disk space to Subspace)
We do start replotting in advance, however, this does not require any extra space allocation. We simply erase the about-to-expire sector and write the same space over.
Do you know how long it takes to:
plot a single sector on a typical machine?
On my M1 Pro it’s ~5 min, however the range is quite wide on other hardware.
gather all the required records for a sector?
I do not have a precise number, but I would put it in the order of seconds.
To put the question differently, what triggers the initial replotting procedure (say I started plotting at Genesis) and what is the earliest time this “Genesis plot/sector” can be expired?
I assumed that all of the dips (roughly every 12.5k blocks starting from just before the 100k-th block) are due to replotting, as you say; and the fact that in “the very end” (around 200k) the dip is bigger is due to only replotting but no much more new space being pledged.
That sounds like a cheat : )
What’s the benefit in doing so? Unless we delete one record at a time such that the farmer always has a full sector minus one record available for auditing at all times.
You can find the algorithm in the consensus specification.
TLDR: if a sector was plotted when history size was n it will expire sometime randomly between n+4 and 4n+4 history size.
