Alex NorthSummary
This is a rough proposal to reduce and simplify the per-sector state accounting cost in order to support higher network capacity. The Filecoin chain state includes a lot of metadata about each sector, most of which is only relevant to deals. Committed-capacity sectors could be made nearly fungible, reducing much of their accounting state to a constant size.
Unfortunately, the need to retain the sealed CID (CommR) for each sector limits the gains. CommR today accounts for just over half of the state, so this proposal gets <2x improvement.
However, this proposal makes those gains by simplifying the state and calculations that we do today, discarding CC sector identities and calculating aggregates instead. These simplifications, or similar ideas, may unlock subsequent improvements that make a bigger difference. Simplifications also simplify reasoning about the current and future protocol, ease migrations to new policies, etc.
Thus, this isn’t a proposal for immediate development, but a sharing of ideas.
See also Filecoin Plus premium and TODO link to Neutron.
Background
The Filecoin network’s growth rate and absolute network size are limited by many linearities involved in onboarding and maintaining storage. In order to unlock very high or exponential growth in committed storage, we need to remove network consensus costs that are linear in storage.
The Filecoin chain state includes information about every sector. A significant amount of per-sector state is relevant only to sectors with deals. A vast majority of sectors, including all incremental network growth today, have no deals. These committed-capacity (i.e. empty) sectors all have the same power but pay similar state & accounting costs as sectors with deals because they share a data schema and accounting process.
Further, a significant amount of per-sector state is maintained for the primary purpose of computing penalties if the sector later faults or is terminated. Every sector has different parameters based on network state when it was committed, deals included, and details of any committed-capacity sector it replaced.
So deals and sector-specific penalties drive heterogeneous sectors, which prevents aggregation and summarisation.
Design proposal
The core idea behind this proposal is to lose the individual identities of committed-capacity sectors as far as possible, maintaining instead an aggregate committed-capacity state for each miner.
Fungible CC sectors do not have individual committed lifetimes, weights, or pledges. They do not expire automatically. Penalties for faulting or terminating a CC sector depend on the miner’s CC aggregate state, not the identity of the sector lost.
Sectors with deals retain their existing schema, although some of the simplifications described below could also be applied.
Per-sector state
Per-sector state is reduced to only a sector number, and sealed CID (CommR), totalling about 40 bytes raw data (a little more with AMT overheads). These two items are required today for Window PoSt computation and verification.
Very roughly, a 100GiB state tree could support ~80EiB worth of 32GiB sectors. TODO: better measurements. (Today, a 14.6 GiB state supports 6EiB (200m sectors) → 78 bytes/sector)
Window PoSt
CC sectors are still scheduled for Window PoSt in fixed-size groups called partitions.
CC sectors are in partitions that contain only CC sectors. Since the sectors are identical, partition state no longer needs to keep track of the aggregate power of live, unproven, faulty or recovering sectors, only the bitfields of sectors in those states (or maybe only even counts). Since sectors do not have pre-specified expiration epochs, the partition does not need to track the expiration queue, nor distinguish early terminations. When bitfields are packed tightly, per-sector partition state cost approaches a low asymptote (TODO: what is it?).
Today, batching/aggregation of Window PoSt submissions is limited by the need to dispute fraudulent proofs. The dispute loads per-sector information for the sector number and CommR for proof verification (still necessary), but incurs the cost of loading all the other per-sector state too (waste). Fungible CC would raise the maximum aggregate/batch size, amortizing overheads.
Note: submitting/verifying the Window PoSt itself is still linear. Other work may aggregate the PoSt verification cost across partitions, removing that linearity.
Expiration & termination
Today, miners nominate an expiration epoch for each sector when committing it. One reason for this is, for sectors with deals, to calculate the sector quality (proportion of sector space*time occupied by verified deals) and hence power. But CC sectors all have the same power, so this is unnecessary. Another reason is to place a lower-bound (180 days) on the duration for which the sector must be committed. The miner can choose a longer expiration, but is not directly incentivized to do so. A longer expiration increases risk of severe penalties, but allows maintenance of power without resealing.
Instead of per-sector nominated expirations, fungible CC tracks the total CC sector count and the sum of the age of all sectors. Sectors don’t expire; a miner must explicitly terminate them. A miner is required to maintain an average sector lifetime above some bound (180 days?). In essence, the network sets the commitment length for all sectors to the minimum, but allows them to remain committed indefinitely beyond that.
When a miner terminates any CC sector, they are taken to have terminated one aged exactly 180 days, regardless of the actual epoch of commitment. Sector count is decremented and the sum of sector age reduced by 180d. If this reduces the average age below 180d, they pay a penalty. Note that a miner maintaining sectors longer than 180d builds up a buffer allowing them to commit and then terminate a new sector before 180d. We might cap the sum of sector ages at 2x the minimum, to limit this buffer.
Today, the narrative of the early termination penalty is to take back all the reward a sector earned, plus 20 more days worth. We could do some similar calculation in terms of reward an average fungible CC has earned.
With fungible CC, a miner no longer needs to trade risk for long-term efficiency when committing. A miner faces a uniform outcome when a sector fails instead of, today, a radically different outcome depending on the sector.
Pledge
A miner maintains a single pledge amount, which covers all their committed storage. The pledge for each new sector is calculated at time of commitment, the same as today, but that number is not associated with the specific sector. Instead the total pledge covers all CC sectors, and a portion may be lost if a sector is terminated early.
This opens the possibility of taking the existing pledge amount into consideration in the computation of the incremental pledge to be added for the new sector. This could unify pledge requirements between miners who commit sectors at different times, which varies today.
Faults & penalties
It is necessary to track the identities of sectors that fault in order to compute Window PoSt for partitions of sectors that include those faults, so fault detection and tracking works similar to today. This also means automatic expiration of sectors fault for 14 days, but the penalty for this is the same as manual termination, and does not depend on the specific sector at fault.
Upgrading CC sectors
Today, upgrading a sector requires recording that sector’s age and daily reward when it was committed, in order to compute termination penalties.
When a fungible CC sector is replaced by another one, the identity of the replaced sector is no longer important. If average CC sector age is > 180d, no termination penalty calculations are needed; otherwise, an average age can be used.