FIPxxxx: Introducing SealerID

Creator

Irene

Created

Mar 8, 2024 10:25 AM

fip	title	author	discussion-to	status	type	category	created
xxxx	Introducing SealerID	kuba, irene, …	https://github.com/filecoin-project/FIPs/discussions/890	Draft	Technical	Core

Simple Summary

Add the notion of SealerID and use if for the sealing process for NI-PoRep. In particular:

We add a new actor, the Sealer Actor so that for SealerIDs can be registered;
SealerID can be used in the method ProveCommitSectorsNIto seal sectors.

Abstract \\todo

a short (~200 word) description of the technical issue being addressed.

Motivation

We consider the scenario where Storage Poviders want to delegate some of their activities to external parties in order to let a competition of service providers optimize and lower the costs.

In particular, we call Sealing-as-a-Service (SaaS) Provider an entity that runs all PoRep operations (labelling the graph, column commitments, MT generation, vanilla proofs and SNARKs generation) needed get a replica (or the sectorKey for CC sector) and onboard the sector that contains it.

The SaaS then transfers the replica (or the key) and the proofs to a SaaS Client. This is an SP that will onboard the sector with the replica R (ie, call a ProveCommit method) and will be responsible of storing R and proving validity of the corresponding sector (ie, running window- and winning-PoSt).

Problems:

[solved already] With interactive PoRep the SaaS Provider and Client needs coordination and agreement (therefore trust) about the intermediate interaction with the chain (ie, sending commR on chain) and locking down PCD (PreCommitDeposit). This is resolved by using NI-PoRep (TODO: link to FIP) that requires no chain interaction and no deposit.
[solved by this FIP] Even with NI-PoRep, some coordination between the SaaS Provider and Client remains. Indeed during the labelling phase the Provider creates ReplicaID and for this needs to use the minerID and sectorNumber from the SaaS Client who will receive the replica to be stored. If these values are not correctly used then the SNARK proof will not be valid. This means that a Providers need to “wait” for the request (and info) from a client to seal sectors. In other words, this prevents a SaaS Provider to seal sectors in advance using its HW at max capacity (and therefore reducing sealing cost for everyone).

Specification

We add a new type of actor: the Sealer Actor (to be used for SaaS Providers);

This can be a “disposable” actor, no need of an owner key. If something bad happen, create a new id. This is okay because no tokens are locked for this actor;

Add the method to create and register SealerID

The list of SealerIDs is disjoint from the MinerID list
Add a new map SealerID -> [SectorNumber] to the chain state (that is, we have a list of used sector numbers for each sealer);

ie, the actor need SectorNumber facilities.

Modify the method ProveCommitSectorsNI to accept the sealerID to create ReplicaID .

Add the SealerID field to SectorNIActivactionInfo

if empty, use the the minerID
if the sealer id is passed, use it for ReplicaID (in the place of miner id)
the method updates the right map of used sector numbers;

[???] Add a boolean variable to ProveCommitSectorsNIParams to tell if the sealer id is used or not

[Access control, needed to avoid front-run attacks]

Store in the Sealer Actor another address: this is an address to a proxy contract that can be used to implement ACL

When an SP onboards a sector (ie, call to method ProveCommitSectorsNIParams in the Miner Actor), then call to the Sealer Actor. If the ACL is enabled, then call to the ACL contract.

Rationale \\todo

The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.

Backwards Compatibility

TODO

Test Cases

TODO

Security Considerations \\wip

For the storage providers, this FIP does not add any security risks respect to the status quo;
For the SaaS provider: there could be the risk of sector to be “stolen” and onboarded by a SP without the SaaS explicit consent.

TO BE DISCUSSED:

Is this a real problem??
If yes, how to solve it? Is ACL enough?

Incentive Considerations

The proposed change (ie, introducing the sealer id to completely decouple computation-heavy task for onboarding sector from the sector ownership) allows SaaS providers to seal sector independently from the current demand and therefore to use their hardware at full capacity. This incentivises the creation of a market for CC sectors and lower the SP cost for onboarding CC sectors, which can later on be upgraded to useful storage via the SnapDeal protocol (ReplicasUpdate3 method).

Product Considerations

Having SaaS providers and CC-sector markets lower the entry barrier for SPs to join the Filecoin network. Indeed, with this service in place SPs do not need to have the HW to run the PoRep step in house. Note that the HW for running winning- and window-PoSt is still needed.

Implementations

TODO

Copyright Waiver

TODOs:

how much expensive (gas cost) is calling the ACL contract?

is there a way to implement access controll that does not involve onchain state? For example, “parsonalize” the snark proof (ie the proof works for a unique minerID)