Merge branch 'master' into master

content/algorithms/expected_consensus/_index.md

@@ -361,7 +361,7 @@ The above case may happen in situations under certain block propagation conditio
 
 Miner 1 outputs their block B and shuts down. Miners 2 and 3 both receive B but not each others' blocks. We have miner 2 mining a Tipset made of B and C and miner 3 mining a Tipset made of B and D. If both succesfully mine blocks now, other miners in the network will receive new blocks built off of Tipsets with equal weight and the same smallest VRF output (that of block B). They should select the block mined atop `[B, C]` since minVRF(C) < minVRF(D).
 
-The probability that two Tipsets with different blocks would have all the same VRF output can be considered negligible: this would amount to finding a collision between two 256-bit (or more) collision-resistant hashes.
+The probability that two Tipsets with different blocks would have all the same VRF output can be considered negligible: this would amount to finding a collision between two 256-bit (or more) collision-resistant hashes. Behaviour is explicitly left unspecified in this case.
 
 ## Finality in EC
 
@@ -397,7 +397,7 @@ This is detectable when a given miner submits two blocks that satisfy any of the
 
 A single consensus fault results into:
 
-- miner termination and removal of power from the power table,
+- miner suspension
 - loss of all pledge collateral (which includes the initial pledge and blocks rewards yet to be vested)
 
 ### Detection and Reporting

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 42 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_markets/storage_market/_index.md

@@ -10,7 +10,7 @@ dashboardTests: 0
 
 # Storage Market in Filecoin
 
-Storage Market subsystem is the data entry point into the network. Storage miners only earn power from data stored in a storage deal and all deals live on the Filecoin network. Specific deal negotiation process happens off chain, clients and miners enter a storage deal after an agreement has been reached and post storage deals on the Filecoin network to earn block rewards and get paid for storing the data in the storage deal. A deal is only valid when it is posted on chain with signatures from both parties and at the time of posting, there are sufficient balances for both parties locked up to honor the deal in terms of deal price and deal collateral.
+Storage Market subsystem is the data entry point into the network. Storage miners can earn power from data stored in a storage deal and all deals live on the Filecoin network. Specific deal negotiation process happens off chain, clients and miners enter a storage deal after an agreement has been reached and post storage deals on the Filecoin network to earn block rewards and get paid for storing the data in the storage deal. A deal is only valid when it is posted on chain with signatures from both parties and at the time of posting, there are sufficient balances for both parties locked up to honor the deal in terms of deal price and deal collateral.
 
 ## Terminology
 

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,19 +17,17 @@ 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 42 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`                                                                                      |
-| `Terminated`   | Either sector is expired, or early terminated by a miner via `miner.TerminateSectors`, or was failed to be proven for 14 consecutive proving periods. |
+| `Terminated`   | Either sector is expired, or early terminated by a miner via `miner.TerminateSectors`, or was failed to be proven for 42 consecutive proving periods. |