[Tracking] Storage Provider Pallet Implementation

[serg-temchenko]

As described in our guidelines in the Storage Provider Pallet section, the StorageMinerActor should be ported as a Substrate pallet.

TODO: @aidan46 needs to define the order in which pallets should be implemented and extend the description accordingly.

[th7nder]

Looks like something I could take. What do you think @aidan46, is it a good candidate to start with?

[th7nder]

We established I'll take #16 first.

[aidan46]

• The storage provider pallet design and documentation have been added in feat: Storage provider design and documentation #56
• Implement storage provider registration (issue: Storage Provider Pallet: Register New Storage Provider #83 & PR: feat: Storage provider registration #82)
• Implement storage provider pre-commit (issue: Storage provider pallet: implement pre commit sector #94 & PR: feat: Add pre commit functionality #93)
• Implement storage provider prove commit (issue: Storage provider pallet: Implement prove commit sector #95 & PR: )
• Implement storage provider submit window PoSt (issue: Storage Provider Pallet: Submit Proof of Spacetime Extrinsic #74 & PR: feat: Implement submit_windowed_post extrinsic #113)
• Implement declaring faults (issue: Storage Provider Pallet: Declaring Faults #75 & PR: )
• Implement faults recovered (issues: SP: Declare faults recovered #164)
• Implement SP pallet hooks (reference PR: feat: Implement SP pallet hooks #125)
  • (issue: SP pallet (hooks): pre-commit hook #103)
  • (issue: SP Pallet (hooks): implement PoSt checking #155)
• Implement missing extrinsics from the CLI (issue: SP: add missing CLI extrinsics from the SP pallet #166)
• Implementing the ExpirationQueue — precendence to terminate_sector and process_early_terminations (issue: SP: port the ExpirationQueue structure/mechanism #165)
• SP Pallet: Add remove_sectors to ExpirationQueue #393
• SP: port process_early_terminations #167
• SP Pallet: Implement terminate_sector #109 (PR: feat(SP pallet): Add terminate sectors extrinsic #462)

Testing — preparing for delivery

• SP pallet: Assess the pre commit tests #118
• SP: Review panic usage  #161
• Storage Provider: verify_deals_for_activation in precommit extrinsic #131
• SP: current_deadline retrieved is wrong #163
• SP: validate chain_commit_block against deadline #170
• SP: PoSt allow proving of multiple partitions per deadline #171
• SP: PoSt proof should fail for wrong sector #172
• SP: Partition not PoSt proved should be marked as faulty #174
• SP: Should fail if the partition is already proven #175
• SP Pallet: Create tests for fault declaration failure scenarios #188
• SP Pallet: Create tests for fault recovery failure scenarios #189

[jmg-duarte]

Logic on the not implemented extrinsics

• control_addresses -> we are only using 1 owner address.
• change_worker_address -> not working with worker addresses.
• apply_rewards -> ties into vesting rewards, a mechanism we do not currently support. Only rewards from deals.
• report_consensus_fault -> part of consensus mechanism, replaced by AURA.
• withdraw_balance -> ties into vesting.
• change_multiaddresses -> no multiaddr support.
• compact_partitions -> cron should do this functionality.
• compact_sector_numbers -> cron should do this functionality.
• confirm_change_worker_address -> not working with worker addresses.
• dispute_windowed_post -> Part of FEVM functionality, not core filecoin.
• prove_replica_updates -> used for changing proof type and proving the updated pof type, we only support 1 proof type atm
• change_beneficiary -> not supporting beneficiaries, only 1 reward address.
• get_beneficiary -> not supporting beneficiaries, only 1 reward address.
• change_peer_id -> could be implemented if needed (i think this was discussed before)
• change_owner_address -> could be implemented if needed (i think this was discussed before)
• check_sector_proven -> could be implemented if needed
• all the getters -> these values can be gotten from the storage map holding all the sp information, if there is a need for these getters they could be implemented.

[cernicc]

Found while creating tests #131

[aidan46]

Some information about the hook implementations:

Pre-commit hook

This hook checks pre-committed sectors for all SPs and checks if the sector is expired (no proof submitted for X amount of time). If the sector is expired, it should remove that sector and burn the SPs initial deposit.

PoSt checking

The PoSt hook needs to check sectors that have been prove committed. It checks if the PoSt deadline has passed for all SPs and their partitions. If any deadlines are past due the SPs initial deposit should be burned and those sectors should be set to faulty. Once a sector is set to fault the SP can recover this sector by calling the declare_faults_recovered extrinsic.

[jmg-duarte]

Closing for now as we've finished the major issues