Add front matter. Reference FRC-0046. Spec new extension method.

FIPS/fip-0045.md

@@ -3,31 +3,82 @@ fip: 0045
 title: De-couple verified registry from markets
 author: Alex North (@anorth)
 discussions-to: https://github.com/filecoin-project/FIPs/discussions/313
-status: Draft type: Technical category : Core created: 2022-08-12 requires: FIP-0034
+status: Draft
+type: Technical
+category : Core
+created: 2022-08-12
+requires: FIP-0034
 ---
 
 TODO:
-- Method for extending a sector, SP provides allocation ids (because market doesn't retain them after deal expiration)
-- Confirm policy for built-in market actor's default term maximum
-- Confirm policy for sector migration any extension to term maximum beyond the sector's lifespan
+- Spec receiver hook on Account, Multisig actors
 - Spec methods for sector migration on miner, market, and verifreg actors
+- Spec change to SectorOnChainInfo to distinguish migrated sectors
+- Discuss changes to deal packing
 - Discuss how market delegate means no external API changes
 - Discuss mechanisms for conditional allocations, negatively priced deals
+- Confirm policy for built-in market actor's default term maximum
+- Confirm policy for sector migration any extension to term maximum beyond the sector's lifespan
 - Market method for fetching allocation ids for deals (needed?)
 - Spec hook/method for a different client extending the claim by spending data cap (needed?).
 
 
 ## Simple Summary
-<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the FIP.-->
-TODO
+Represents Filecoin Plus data cap allocations separately from the built-in market actor.
+Adds explicit term (duration) limits to data cap allocations.
+Simplifies the quality-adjusted power calculation to remove spreading out over a sector's lifetime.
+Supports extending the terms of data cap allocations independently of market deals.
+Represents un-allocated data cap as a fungible token.
+These changes provide a foundation for user-programmed market actors to broker Filecoin Plus verified deals in the future.
 
 ## Abstract
-<!--A short (~200 word) description of the technical issue being addressed.-->
-TODO
+The current implementation of Filecoin Plus verified deals is deeply coupled to the built-in market actor,
+which is treated as trusted code.
+The built-in market is inefficient, limited in functionality and can only improve very slowly through network upgrades.
+The architectural coupling prevents any user-programmed actors from replicating, improving, or varying deal-related functionality,
+especially with any relation to Filecoin Plus.
+
+This proposal decouples the representation of Filecoin Plus data cap allocations from the built-in market actor's deals, 
+and the process of claiming it from the built-in market's processes.
+The built-in market actor remains a delegate, acting on behalf of verified clients,
+but only in a way that will be accessible to user-programmed market actors too.
+This removes some of the necessary trust vested in the built-in market actor's code. 
+
+Along the way, this proposal implements the ability to extend data cap terms beyond the market's deal terms.
+It also simplifies the quality adjusted power calculation so as to support
+the future ability to update the data in a sector regardless of its previous content.
+This proposal gets half way toward full support for user-programmed market actors.
 
 ## Change Motivation
-<!--The motivation is critical for FIPs that want to change the Filecoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.-->
-TODO
+The core motivation behind this proposal is to enable the development of markets and market-like actors
+on the FVM, once user-programability is supported.
+All negotiation between data clients and storage providers is currently limited by 
+the built-in market actor's limited abilities,
+and improvements to it are thus limited to FIPs and network upgrades.
+Features like deal extension, multi-sector deals, re-negotiation, deal transfer, capacity deals,
+auction markets, repair markets, insurance, derivatives etc. should all be possible in user-programmed actors.
+None should require a network-wide upgrade to realise.
+
+The built-in market actor currently occupies an exclusive position as the sole broker of
+Filecoin Plus data cap, tightly coupled with the verified registry and storage miner actors.
+In order to enable the development of useful storage-related applications and features,
+we need to break the tight coupling between the built-in actors, expose composable on-chain primitives,
+and make the capabilities of the built-in market actor available to user-programmable contracts.
+This proposal addresses the capability to broker of Filecoin Plus data cap.
+
+Breaking coupling between the built-in market actor, verified registry actor, and miner actors 
+will eventually remove the storage market from consensus-critical risk surface,
+and move subsequent market development into the realm of smart-contract upgrades,
+rather than network-wide consensus protocol upgrades.
+Minimising coupling is a key principle in software and systems engineering. 
+Decoupling the verified data rewards from storage deals provides great opportunities for 
+simplifying Filecoin’s core mechanics in order to provide a better platform for development.
+
+One benefit we can immediately realise is simplifying the calculation of quality-adjusted power. 
+The current mechanism, which is coupled to deal terms, imposes significant limits on the flexibility of sector storage,
+essentially rendering it write-once. 
+Decoupling these neatly resolves the calculation difficulties to give full flexibility, 
+and is much simpler than the Filecoin Plus premium proposal that also attempted this.
 
 ## Specification
 **Terminology**
@@ -172,15 +223,19 @@ struct SectorAllocationClaim {
     // The (padded) size of the data committed (up to the allocation's data size).
     PieceSize: uint64
     // The sector into which the piece has been committed.
-    SectorID: uint64,
+    SectorID: uint64
+    // The epoch during which the sector is scheduled to expire.
+    SectorExpiration: int64
  
 }
 struct ClaimAllocationsParams {
     Sectors: []SectorAllocationClaim
 }
 struct SectorClaimResult {
-    // Indices of allocation claims in the parameters that succeeded.
-    Successful: []int64
+    // Count of successful claims.
+    SuccessCount: uint64
+    // Index and failure code for each unsuccessful claim.
+    Failures: []{index: uint64, code: ExitCode}
 }
 // Called by storage miner actor to claim allocations for data provably committed to storage.
 // For each allocation claim, the registry checks that the provided piece CID
@@ -221,8 +276,10 @@ struct ExtendClaimTermsParams{
     Claims: []ClaimTerm
 }
 struct ExtendClaimTermsResult {
-    // Indices of extensions that succeeded.
-    Successful: []int64
+    // Count of successful extensions.
+    SuccessCount: uint64
+    // Index and failure code for each unsuccessful extension.
+    Failures: []{index: uint64, code: ExitCode}
 }
 
 // Called by allocation client to extend the maximum term of their allocations, 
@@ -236,27 +293,27 @@ fn ExtendClaimTerms(params: ExtendClaimTermsParams) -> ExtendClaimTermsResult
 The `Clients` map of addreses to balances is removed from the verified registry state.
 The balances of data cap tokens held by verified clients are extracted to a data cap token actor.
 This actor represents un-allocated data cap as a fungible token.
+This token actor is intended to implement the FRC-0046 token standard in the future,
+but specification of the full, public API is deferred to a subsequent proposal.
+The data cap token actor should be retroactively updated to support the standard later.
+
 Token balances are represented as BigIntegers with 18 decimal places of precision, 
 a representation which is likely to be adopted by future token standards.
 Token quantities are constrained to be whole multiples of `10^18`. 
 One whole data cap token corresponds to one unit of data cap to be allocated,
 which today is good for one byte of data.
-
 The data cap token is generally non-transferable, except to or from the verified registry actor.
 The token actor enforces these transfer restrictions.
 The verified registry actor can invoke privileged methods to create and destroy tokens.
 
-A token standard is expected to support delegation of control of token balances to specified
-third-party actors.
-The built-in storage market actor is pre-authorized as a delegate for all verified clients.
+FRC-0046 supports delegation of control of token balances to specified third-party actors as "operators".
+The built-in storage market actor is pre-authorized as an operator for all verified clients.
 Thus, the built-in market actor can allocate data cap on clients' behalf.
-This mechanism allows this proposal to be impelemented without changing any clients' or
-providers' workflows.
-It also will support user-programmed market actors dealing in data cap in the future.
-The data cap token actor is intended to present a public interface conforming to standards for
-fungible token behaviour and an extensible calling convention.
-Neither of those standards are pre-requisite for this proposal, however.
-The built-in actors will be retroactively updated to support those standards when they settle.
+This delegation mechanism will support user-programmed market actors dealing in data cap in the future.
+
+This token delegation mechanism allows this proposal to be implemented without changing any
+clients' or providers' workflows for existing functionality.
+Parties will continue to interact with the built-in market actor and verified registry actor directly.
 
 #### Operations
 The `AddVerifiedClient` method is changed to invoke the data cap token actor to
@@ -274,7 +331,7 @@ data cap tokens back to the client's balance for re-use.
 
 ### Simplified quality-adjusted power
 A data cap allocation/claim is valid for a range of commitment terms, between a client-specified
-minimum and maximum.
+minimum and maximum, so long as the allocation is claimed before the allocation expires.
 
 The actual term for a claim begins at the epoch the data is committed into a sector,
 proven either with proof-of-replication or replica-update. 
@@ -347,7 +404,43 @@ This facility to drop a claim can only be exercised:
 - in the final 30 days of the sector's currently committed lifespan
 
 These restrictions prevent a provider using extension as a means of escaping their commitment to 
-store the claimed piece for the sector’s full originally-committed lifetime. 
+store the claimed piece for the sector’s full originally-committed lifetime.
+
+The storage provider operator must provide the IDs of the allocations claimed by the sector when extending.
+
+```
+// The verified data claims currently supported by a sector, to be maintained or dropped
+// while processing extension.
+// All claims currently supported by the sector must be provided.
+struct SectorClaims {
+    Sector: uint64,
+    MaintainClaims: []ClaimID
+    DropClaims: []ClaimID
+}
+struct ExpirationExtension2 {
+    Deadline: uint64,
+    Partition: uint64,
+    Sectors: BitField, // IDs of non-FIL+ sectors (must have zero verified deal weight)
+    SectorsWithClaims: []SectorClaims
+    NewExpiration: int64, // epoch
+}
+struct ExtendSectorExpirationParams2 {
+    Extensions: []ExpirationExtension2,
+}
+struct ExtendSectorExpirationResult2 {
+    // Count of successful extensions.
+    SuccessCount: uint64
+    // Index and failure code for each unsuccessful extension.
+    Failures: []{index: uint64, code: ExitCode}
+}
+
+// Increases the expiration epoch for some sectors, optionally dropping expired claims.
+// For each sector, the provided claim IDs must correspond to claims that refer back to the 
+// sector, and the sum of their size must equal the sector's verified deal weight.
+// The new expiration must be prior to the earliest term maximum for any maintained claims.
+fn ExtendSectorExpiration2(params: ExtendSectorExpirationParams2) -> ExtendSectorExpirationResult2
+
+```
 
 ### Built-in storage market as a delegate
 The workflows described above are independent of any market actor, 
@@ -377,16 +470,24 @@ let dealAllocation = Allocation {
   }
 ```
 
-The market stores the allocation ID in deal state.
+The market stores allocation IDs for not-yet-activated deals in a new mapping, 
+and the claim ID for activated deals in deal state.
 
 ```
+struct State {
+  // Remainder unchanged...
+  
+  // Allocation IDs for deals that are not yet activated.
+  PendingDealAllocationIDs CID // HAMT[DealID]AllocationID
+}
+
 struct DealState {
   // Existing state
   SectorStartEpoch: int64,
   LastUpdatedEpoch: int64,
   SlashEpoch: int64,
   // New
-  AllocationID: uint64
+  ClaimID: uint64
 }
 ```
 
@@ -405,17 +506,22 @@ TODO!
 The power for existing sectors is not changed by this proposal.
 
 A provider may opt-in to migrate a sector to the new QA power calculation method.
+Each active deal is converted to a claim as if an allocation had been created when the deal was made.
+The claim's minimum term is the deal's duration, and maximum term is the sector's current expiration epoch
+(TODO: plus some buffer?).
+
+Expired deals cannot be migrated, even though the old QA power calculation method has spread out
+their power and reward over the sector's full lifetime.
+This will generally result in an increase in power for a sector, 
+but may result in a decrease in case of expired deals.
+This is why the migration is opt-in.
+
 A new method on the storage miner actor:
 - Fetches information about each not-yet-expired verified deal from the market
 - Calls the verified registry to create a claim for each such deal.
-  The claim's minimum term is the deal's duration, and maximum term is the sector's current expiration epoch
-  (TODO: plus some buffer?)
 - Re-calculates power according to the amount of space committed to active claims. 
-
-This will generally result in an increase in power for the sector.
-Note that power may be lost for deals that have already expired,
-but which weight was previously amortized over the sector lifespan.
-
+- Re-caclulates pledge requirement according to the new power and network conditions (but never decreases) 
+
 After migration, the client can extend the migrated claims' terms up to the network policy maximum.
 After claims are extended, the provider can extend the sector commitment duration to match.
 Note that a migrated sector cannot be extended unless the claim terms are extended,