Future Compatibility for PreCommit with UnsealedSectorCID

[Kubuxu]

Today, PreCommit accepts DealID and later based on it looks up UnsealedSectorCID. Future changes, with high probability, will move away from that approach, towards accepting UnsealedSectorCID directly.

I propose we add PreCommitSector2 and PreCommitSectorBatch2 capable of accepting UnsealedSectorCID directly.

Motivation

When there is a necessary change in parameters of an actor's method exposed to users, the cleanest mechanism to execute such change is to add a new method and permissively continue to accept calls to the old method.
This mechanism increases implementation complexity as old code pathways have to continue functioning.
In this case, the motivating factors for the change are User Deployable Storage Markets and FVM Programmability. These two, by themselves, will be complex changes to built-in actors.
By introducing new method signatures before behavioural changes, the primary change can omit compatibility with old method signatures and thus reduce their complexity and work required.

Proposal

Modify SectorPrecommitInfo to accept UnsealedSectorCID and remove unused fields, while maintaining old function signatures of PreCommitSector and PrecommitSectorBatch which will forward messages to their *2 variants with unsealed_sector_cid = None.

pub struct SectorPreCommitInfo {
    pub seal_proof: RegisteredSealProof,
    pub sector_number: SectorNumber,
    pub sealed_cid: Cid,
    pub seal_rand_epoch: ChainEpoch,
    pub deal_ids: Vec<DealID>,
    pub expiration: ChainEpoch,
-   pub replace_capacity: bool,
-   pub replace_sector_deadline: u64,
-   pub replace_sector_partition: u64,
-   pub replace_sector_number: SectorNumber,
+   pub unsealed_sector_cid: Option<Cid>,
}

Introduce two new methods to the Miner actor PreCommitSector2 and PreCommitSectorBatch2 using the new SectorPreCommitInfo.
Perform migration of the SectorPreCommitOnChainInfo filling out unsealed_sector_cid field with None.

[anorth]

Thanks @Kubuxu, 💯 .

I'm restating a bit of the background here to refresh it for myself, and others. The sector proving protocol requires providers to commit to the sector data (UnsealedSectorCID, aka CommD) at pre-commit time. The current flow does so indirectly: the provider gives the deal IDs at pre-commit time, and the miner actor later on gets the UnsealedSectorCID by asking the built-in market actor to compute it.
This scheme only works because there's a single built-in market actor, and the protocol trusts it for this computation. We want to decouple these things to allow for user-programmed market actors and other storage contracts.
This proposal has the provider commit to the UnsealedSectorCID directly during pre-commit. The miner actor will confirm that this matches the deal IDs.
In the future, deals will not be specified at pre-commit (the parameter will become redundant). Instead, pieces of data that comprise the sector will be declared at prove-commit time (with inclusion proofs to the UnsealedSectorCID) and these piece CIDs can be pushed to market contracts, which can trust the miner actor.

Introducing the new pre-commit parameters now will give operators many months to transition to calling them, before we deprecate the old methods when enabling user-programmable markets. We expect these new parameters to be the right ones for the future (albeit with pre-commit deal IDs redundant/ignored).

[anorth]

I note that this change is complementary to FIP-0034, setting fixed PCD. Prototyping that code is how we discovered this forward-compatibility issue in the first place. We then were able to separate that FIP's functional change from this forward compatibility change for clarity, but it would be easiest to implement both of them in the same network upgrade.

[f8-ptrk]

will this have an impact on gas_used?

[Kubuxu]

These will be just new methods for future use but assuming you start using them early it shouldn't increase gas usage by more than ~48k gas(cost of passing CommD in the message).

[jennijuju]

This FIP is accepted as of aug 29th.