Skip to content

Latest commit

 

History

History
116 lines (95 loc) · 8.48 KB

fip-0041.md

File metadata and controls

116 lines (95 loc) · 8.48 KB
fip title author discussions-to status type category created
0041
Forward Compatibility for PreCommit and ReplicaUpdate
Jakub Sztandera (@Kubuxu)
Accepted
Technical
Core
2022-06-29

FIP-0041: Forward Compatibility for PreCommit and ReplicaUpdate

Simple Summary

Introduce new versions of PreCommitBatch and ProveReplicaUpdates methods such that future update is easier to perform.

Abstract

In close future we expect a change in storage market mechanisms to recognise UnsealedSectorCID as primary identifier of data. This would require PreCommitBatch and ProveReplicaUpdates to accept UnsealedSectorCID. We propose adding variants of these methods capable of accepting UnsealedSectorCID today for a more straightforward upgrade in the future.

Change 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.

Specification

Within Miner actor, introduce a new method number 28, called PreCommitSectorBatch2 which is a copy of PreCommitSectorBatch with following changes:

  • remove of fields related to deprecated and non-functional CC upgrade.
  • introduce a unsealed_sector_cid field, a tagged union of Cid and None. None signifies a UnsealedSectorCID of sector containing just zeros (CC sector).
  • verify that the UnsealedSectorCID is consistent with UnsealedSectorCID computed from DealIDs.
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>,
}

Within Miner actor, introduce a new method number 29, called ProveReplicaUpdates2 which is a copy of ProveReplicaUpdates with following changes:

  • introduce a new_unsealed_cid field of type Cid.
  • verify that the UnsealedSectorCID is consistent with UnsealedSectorCID computed from DealIDs.
pub struct ReplicaUpdate2 {
    pub sector_number: SectorNumber,
    pub deadline: u64,
    pub partition: u64,
    pub new_sealed_cid: Cid,
+   pub new_unsealed_cid: Cid,
    pub deals: Vec<DealID>,
    pub update_proof_type: RegisteredUpdateProof,
    #[serde(with = "serde_bytes")]
    pub replica_proof: Vec<u8>,
}

Design Rationale

Tagged union type was selected from PreCommitSectorBatch2 to save on storing repeated UnsealedSectorCIDs for CC sectors containing zeros as there exist a function ZeroUnsealedSectorCID(PoRepType) capable of producing it.

ProveReplicaUpdates2 uses an explicit UnsealedSectorCID as the ZeroUnsealedSectorCID is expected to be rare for this function.

Backwards Compatibility

This change requires a network upgrade but otherwise is backwards compatible. The older variants of newly introduced functions should be deprecated.

Test Cases

Test cases for an implementation are mandatory for FIPs that are affecting consensus changes. Other FIPs can choose to include links to test cases if applicable.

Security Considerations

This FIP doesn't introduce significant functional changes which would have an effect on security.

Incentive Considerations

This FIP doesn't introduce significant functional changes which would have an effect on incentive structure.

Product Considerations

This FIP doesn't introduce significant functional changes which would have an effect on product.

Implementation

This FIP is being worked on as part of the FIP-0034 implementation as both require similar changes in the same part of the codebase.

Copyright

Copyright and related rights waived via CC0.