Feat/update fip0008 fip0013 (filecoin-project#1263)

* Add batch method references

* Add more references + fix some obvious out dated text

* Attempt format fix

* Fix typo to respin CI in case its just flaky

* Update content/systems/filecoin_mining/storage_mining/_index.md

Co-authored-by: Steven Allen <[email protected]>

* Update content/systems/filecoin_mining/sector/adding_storage.md

Co-authored-by: ZenGround0 <[email protected]>
Co-authored-by: Jiaying Wang <[email protected]>
Co-authored-by: Steven Allen <[email protected]>

content/algorithms/pos/post.md

@@ -50,7 +50,7 @@ The Filecoin network expects constant availability of stored files. Failing to s
 
 ## Design
 
-Each miner actor is allocated a 24-hr proving period at random upon creation. This proving period is divided into 48 non-overlapping half-hour deadlines. Each sector is assigned to one of these deadlines when proven to the chain, i.e., when `ProveCommit` completes and never changes deadline. The sets of sectors due at each deadline is recorded in a collection of 48 bitfields.
+Each miner actor is allocated a 24-hr proving period at random upon creation. This proving period is divided into 48 non-overlapping half-hour deadlines. Each sector is assigned to one of these deadlines when proven to the chain, i.e., when ProveCommit completes and never changes deadline. The sets of sectors due at each deadline is recorded in a collection of 48 bitfields.
 
 Generally, sectors are first allocated to fill any deadline up to the next whole-partition multiple of (2349) sectors; next a new partition is started on the deadline with the fewest partitions. If all deadlines have the same number of sectors, a new partition is opened at deadline 0.
 
@@ -71,10 +71,10 @@ Summarising:
 - A _proving period_ is evenly divided in `WPoStPeriodDeadlines` _deadlines_.
 - Each miner has a different start of proving period `ProvingPeriodStart` that is assigned at `Power.CreateMiner`.
 - A _deadline_ is a period of `WPoStChallengeWindow` epochs that divides a proving period.
-- Sectors are assigned to a deadline on `miner.ProveCommitSector` and will remain assigned to it throughout their lifetime.
+- Sectors are assigned to a deadline at ProveCommit, either a call to `miner.ProveCommitSector` or `miner.ProveCommitAggregate`, and will remain assigned to it throughout their lifetime.
 - In order to prove that they continuously store a sector, a miner must submit a `miner.SubmitWindowedPoSt` for each deadline.
 - Sectors are assigned to partitions. A partition is a set of sectors that is not larger than the Seal Proof allowed number of sectors `sp.WindowPoStPartitionSectors`.
-- Sectors are assigned to a partition at `miner.ProveCommitSector` and they can be re-arranged via `CompactPartitions`.
+- Sectors are assigned to a partition at ProveCommit, through a call to `miner.ProveCommitSector` or `miner.ProveCommitAggregate`, and they can be re-arranged via `CompactPartitions`.
 - Partitions are a by-product of our current proof mechanism. There is a limit in the number of sectors (`sp.WindowPoStPartitionSectors`) that can be proven in a single SNARK proof. If more than this amount is required to be proven, more than one SNARK proof is required, given that each SNARK proof represents a partition.
 
 There are four relevant epochs associated to a deadline, shown in the table below:

content/systems/filecoin_blockchain/storage_power_consensus/storage_power_actor.md

@@ -32,7 +32,7 @@ The Miner lifecycle in the power table should be roughly as follows:
 
 - `MinerRegistration`: A new miner with an associated worker public key and address is registered on the power table by the storage mining subsystem, along with their associated sector size (there is only one per worker).
 - `UpdatePower`: These power increments and decrements are called by various storage actors (and must thus be verified by every full node on the network). Specifically:
- - Power is incremented at `SectorProveCommit`
+ - Power is incremented at ProveCommit, as a subcall of `miner.ProveCommitSector` or `miner.ProveCommitAggregate`
  - Power of a partition is decremented immediately after a missed WindowPoSt (`DetectedFault`).
  - A particular sector's power is decremented when it enters into a faulty state either through Declared Faults or Skipped Faults.
  - A particular sector's power is added back after recovery is declared and proven by PoSt.

content/systems/filecoin_markets/onchain_storage_market/storage_deal_flow.md

@@ -25,7 +25,7 @@ dashboardTests: 0
 
 ## Sealing sectors
 
-4. Once a miner finishes packing a `Sector`, it generates a `SectorPreCommitInfo` and calls `PreCommitSector` with a `PreCommitDeposit`. It must call `ProveCommitSector` with `SectorProveCommitInfo` within some bound to recover the deposit. Initial pledge will then be required at `ProveCommit`. Initial Pledge is usually higher than `PreCommitDeposit`. Recovered `PreCommitDeposit` will count towards Initial Pledge and miners only need to top up additional funds at `ProveCommit`. Excess `PreCommitDeposit`, when it is greater than Initial Pledge, will be returned to the miner. An expired `PreCommit` message will result in `PreCommitDeposit` being burned. All Sectors have an explicit expiration epoch declared during `PreCommit`. For sectors with deals, all deals must expire before sector expiration. The Miner gains power for this particular sector upon successful `ProveCommit`. For more details on the Sectors and the different types of deals that can be included in a Sector refer to the [Sector section](filecoin_mining#sector).
+4. Once a miner finishes packing a `Sector`, it generates a `SectorPreCommitInfo` and calls `PreCommitSector` or `PreCommitSectorBatch` with a `PreCommitDeposit`. It must call `ProveCommitSector` or `ProveCommitAggregate with `SectorProveCommitInfo`within some bound to recover the deposit. Initial pledge will then be required at time of`ProveCommit`. Initial Pledge is usually higher than `PreCommitDeposit`. Recovered `PreCommitDeposit`will count towards Initial Pledge and miners only need to top up additional funds at`ProveCommit`. Excess `PreCommitDeposit`, when it is greater than Initial Pledge, will be returned to the miner. An expired `PreCommit`message will result in`PreCommitDeposit`being burned. All Sectors have an explicit expiration epoch declared during`PreCommit`. For sectors with deals, all deals must expire before sector expiration. The Miner gains power for this particular sector upon successful `ProveCommit`. For more details on the Sectors and the different types of deals that can be included in a Sector refer to the [Sector section](filecoin_mining#sector).
 
 ## Prove Storage
 
@@ -51,7 +51,7 @@ dashboardTests: 0
 
 ## Sector Termination
 
-12. Termination of a sector can be triggered in two ways. One when sector remains faulty for 14 consecutive days and the other when a miner initiates a termination by calling `TerminateSectors`. In both cases, a `TerminationFee` is penalized, which is in principle equivalent to how much the sector has earned so far. Miners are also penalized for the `DealCollateral` that the sector contains and remaining `DealPayement` will be returned to clients.
+12. Termination of a sector can be triggered in two ways. One when sector remains faulty for 14 consecutive days and the other when a miner initiates a termination by calling `TerminateSectors`. In both cases, a `TerminationFee` is penalized, which is in principle equivalent to how much the sector has earned so far. Miners are also penalized for the `DealCollateral` that the sector contains and remaining `DealPayment` will be returned to clients.
 
 ## Deal Payment and slashing
 

content/systems/filecoin_markets/onchain_storage_market/storage_deal_states.md

@@ -23,8 +23,8 @@ Note that `Unpublished` and `Deleted` states are not tracked on chain. To reduce
 The following describes how a deal transitions between its different states. These states in the list below are **on-chain states** understood by the actor/VM logic.
 
 - `Unpublished -> Published`: this is triggered by `StorageMarketActor.PublishStorageDeals` which validates new storage deals, locks necessary funds, generates deal IDs, and registers the storage deals in `StorageMarketActor`.
-- `Published -> Deleted`: this is triggered by `StorageMinerActor.ProveCommitSector` during InteractivePoRep when the elapsed number of epochs between PreCommit and ProveCommit messages exceeds `MAX_PROVE_COMMIT_SECTOR_EPOCH`. ProveCommitSector will also trigger garbage collection on the list of published storage deals.
-- `Published -> Active`: this is triggered by `ActivateStorageDeals` after successful `StorageMinerActor.ProveCommitSector`. It is okay for the StorageDeal to have already started (i.e. for `StartEpoch` to have passed) at this point but it must not have expired.
+- `Published -> Deleted`: this is triggered by `StorageMinerActor.ProveCommitSector` or `StorageMinerActor.ProveCommitAggregate` during InteractivePoRep when the elapsed number of epochs between PreCommit and ProveCommit messages exceeds `MAX_PROVE_COMMIT_SECTOR_EPOCH`. The ProveCommit message will also trigger garbage collection on the list of published storage deals.
+- `Published -> Active`: this is triggered by `ActivateStorageDeals` after successful `StorageMinerActor.ProveCommitSector` or `StorageMinerActor.ProveCommitAggregate`. It is okay for the StorageDeal to have already started (i.e. for `StartEpoch` to have passed) at this point but it must not have expired.
 - `Active -> Deleted`: this can happen under the following conditions:
  - The deal itself has expired. This is triggered by `StorageMinerActorCode._submitPowerReport` which is called whenever a PoSt is submitted. Power associated with the deal will be lost, collaterals returned, and all remaining storage fees unlocked (allowing miners to call `WithdrawBalance` successfully).
  - The sector containing the deal has expired. This is triggered by `StorageMinerActorCode._submitPowerReport` which is called whenver a PoSt is submitted. Power associated with the deals in the sector will be lost, collaterals returned, and all remaining storage fees unlocked.

content/systems/filecoin_mining/sector/adding_storage.md

@@ -11,8 +11,8 @@ dashboardTests: 0
 
 A Miner adds more storage in the form of Sectors. Adding more storage is a two-step process:
 
-1. **PreCommitting a Sector**: A Miner publishes a Sector's SealedCID and makes a deposit. The Sector is now registered to the Miner, and the Miner must ProveCommit the Sector or lose their deposit.
-2. **ProveCommitting a Sector**: The Miner provides a Proof of Replication (PoRep) for the Sector. This proof must be submitted AFTER a delay (the InteractiveEpoch), and BEFORE PreCommit expiration.
+1. **PreCommitting a Sector**: A Miner publishes a Sector's SealedCID, through `miner.PreCommitSector` of `miner.PreCommitSectorBatch`, and makes a deposit. The Sector is now registered to the Miner, and the Miner must ProveCommit the Sector or lose their deposit.
+2. **ProveCommitting a Sector**: The Miner provides a Proof of Replication (PoRep) for the Sector through miner.ProveCommitSector or miner.ProveCommitAggregate. This proof must be submitted AFTER a delay (the InteractiveEpoch), and BEFORE PreCommit expiration.
 
 This two-step process provides assurance that the Miner's PoRep _actually proves_ that the Miner has replicated the Sector data and is generating proofs from it:
 

content/systems/filecoin_mining/sector/lifecycle.md

@@ -17,18 +17,16 @@ It is reasonable to assume that miners enter the network by adding Committed Cap
 
 All sectors are expected to remain live until the end of their sector lifetime and early dropping of sectors will result in slashing. This is done to provide clients a certain level of guarantee on the reliability of their hosted data. Sector termination can comes with a corresponding _termination fee_.
 
-As with every system it is expected that sectors will present faults. Although this might degrade the quality offered by the network, the reaction of the miner to the fault drives system decisions on whether or not the miner should be penalized. If a fault is reported immediately after it is detected by the miner, then the penalty fee is much lower than if the system detects the defect through wrong (or non-existent) PoSt submission.
-
-An adjacent concept to the sector _fault_ is sector _recovery_, that is, how quickly and if the miner attempts to recover the sector and bring it back to normal operation. Therefore, in case of a faulty sector, a small penalty fee approximately equal to the block reward that the sector would win per day is applied. The fee is calculated per day of the sector being unavailable to the network.
+As with every system it is expected that sectors will present faults. Although this might degrade the quality offered by the network, the reaction of the miner to the fault drives system decisions on whether or not the miner should be penalized. A miner can recover the faulty sector, let the system terminate the sector automatically after 14 days of faults, or proactively terminate the sector immediately in the case of unrecoverable data loss. In case of a faulty sector, a small penalty fee approximately equal to the block reward that the sector would win per day is applied. The fee is calculated per day of the sector being unavailable to the network, i.e. until the sector is recovered or terminated.
 
 Miners can extend the lifetime of a sector at any time, though the sector will be expected to remain live until it has reached the end of the new sector lifetime. This can be done by submitting a `ExtendedSectorExpiration` message to the chain.
 
 A sector can be in one of the following states.
 
 | State | Description |
 | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `Precommitted` | Miner seals sector and submits `miner.PreCommitSector`   |
-| `Committed` | Miner generates a Seal proof and submits `miner.ProveCommitSector`   |
+| `Precommitted` | Miner seals sector and submits `miner.PreCommitSector` or `miner.PreCommitSectorBatch` |
+| `Committed` | Miner generates a Seal proof and submits `miner.ProveCommitSector` or `miner.ProveCommitAggregate` |
 | `Active` | Miner generate valid PoSt proofs and timely submits `miner.SubmitWindowedPoSt` |
 | `Faulty` | Miner fails to generate a proof (see Fault section) |
 | `Recovering` | Miner declared a faulty sector via `miner.DeclareFaultRecovered` |

content/systems/filecoin_mining/sector/sector-faults.md

@@ -9,8 +9,7 @@ dashboardTests: 0
 
 # Sector Faults
 
-It is very important for storage providers to have a strong incentive to both report the failure to the chain and attempt recovery from the fault in order to uphold the storage guarantee for the networkʼs clients. Without this incentive, it is impossible to distinguish an honest minerʼs hardware failure from malicious behavior, which is necessary to treat miners fairly. The size of the fault fees depend on the severity of the failure and the rewards that the miner is expected to earn from the sector to make sure incentives are aligned. The three types of sector storage fault fees are:
+It is very important for storage providers to have a strong incentive to both report the failure to the chain and attempt recovery from the fault in order to uphold the storage guarantee for the networkʼs clients. Without this incentive, it is impossible to distinguish an honest minerʼs hardware failure from malicious behavior, which is necessary to treat miners fairly. The size of the fault fees depend on the severity of the failure and the rewards that the miner is expected to earn from the sector to make sure incentives are aligned. The two types of sector storage fault fees are:
 
-- **Sector fault fee:** This fee is paid per sector per day while the sector is in a faulty state. The size of the fee is slightly more than the amount the sector is expected to earn per day in block rewards. If a sector remains faulty for more than 2 consecutive weeks, the sector will pay a termination fee and be _removed from the chain state_. As storage miner reliability increases above a reasonable threshold, the risk posed by these fees decreases rapidly.
-- **Sector fault detection fee:** This is a one-time fee paid in the event of a failure if the miner does not report it honestly and instead the unreported failure is caught by the chain. Given the probabilistic nature of our PoSt checks, this is set to a few days worth of block reward that would be expected to be earned by a particular sector.
+- **Sector fault fee:** This fee is paid per sector per day while the sector is in a faulty state. This fee is not paid the first day the system detects the fault allowing a one day grace period for recovery without fee. The size of the sector fault fee is slightly more than the amount the sector is expected to earn per day in block rewards. If a sector remains faulty for more than 14 consecutive days, the sector will pay a termination fee and be _removed from the chain state_. As storage miner reliability increases above a reasonable threshold, the risk posed by these fees decreases rapidly.
 - **Sector termination fee:** A sector can be terminated before its expiration through automatic faults or miner decisions. A termination fee is charged that is, in principle, equivalent to how much a sector has earned so far, up to a limit in order to avoid discouraging long sector lifetimes. In an active termination, the miner decides to stop mining and they pay a fee to leave. In a fault termination, a sector is in a faulty state for too long, and the chain terminates the deal, returns unpaid deal fees to the client and penalizes the miner. Termination fee is currently capped at 90 days worth of block reward that a sector will earn. Miners are responsible for deciding to comply with local regulations, and may sometimes need to accept a termination fee for complying with content laws. Many of the concepts and parameters above make use of the notion of “how much a sector would have earned in a day” in order to understand and align incentives for participants. This concept is robustly tracked and extrapolated on chain.

content/systems/filecoin_mining/sector/sector-quality/_index.md

@@ -57,4 +57,4 @@ The _Sector Quality Adjusted Power_ is:
 $sectorQuality = avgQuality*size$
 {{</katex>}}
 
-During `miner.PreCommitSector`, the sector quality is calculated and stored in the sector information.
+During `miner.PreCommitSector` and `miner.PreCommitSectorBatch`, the sector quality is calculated and stored in the sector information.