From 2b95255867c4115505939e65f369c905ceb185cb Mon Sep 17 00:00:00 2001 From: Irene <23217773+irenegia@users.noreply.github.com> Date: Wed, 17 Apr 2024 15:48:11 +0200 Subject: [PATCH 01/11] Create fip-xxx-sealerid.md This proposal introduced the sealerID. This is a new identifier created for parties that participate to the Filecoin network by creating replicas, which can then transferred to SPs. This fully enables the Sealing-as-a-Service scenario already introduced in FIP0090 (NI-PoRep). Discussion: #890 --- FIPS/fip-xxx-sealerid.md | 144 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 FIPS/fip-xxx-sealerid.md diff --git a/FIPS/fip-xxx-sealerid.md b/FIPS/fip-xxx-sealerid.md new file mode 100644 index 000000000..42df88a7f --- /dev/null +++ b/FIPS/fip-xxx-sealerid.md @@ -0,0 +1,144 @@ + +# FIPxxxx: Introducing SealerID + + +## Public doc + + + + + + + + + + + + + + + + + + + + + + + +
fip + title + author + discussion-to + status + type + category + created +
xxxx + Introducing sealerID + kuba (@kubuku), irene (@irenegia), luca (@lucaniz) + https://github.com/filecoin-project/FIPs/discussions/890 + Draft + Technical + Core + 17th April 2024 +
+ + + +## Simple Summary + +Add the notion of `sealerID` and use it 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 `ProveCommitSectorsNI` to seal sectors. + + +## Abstract + +With the current protocol, when a party creates `ReplicaID` needs to use the same `minerID` that will be used for PoRep verifications. This implies that “pre-sealing” sector is not a viable option: no sector can be sealed (ie, replica created) ahead of time, before knowing the identity of the SPs who will own it. To enable this scenario we introduce the concept of `sealerID` to be used in the place of the `minerID` only during sealing. + + +## Motivation + +We consider the scenario where Storage Providers 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 (labeling the graph, column commitments, MT generation, vanilla proofs and SNARKs generation) needed to get a replica and onboard the sector that contains it. + +The SaaS then transfers the replica 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 for storing R and proving validity of the corresponding sector (ie, running window- and winning-PoSt). + + +### Addressed issues: + + + +1. [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 [FIP0090](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0090.md) that requires no chain interaction and no deposit. +2. [solved by this FIP] Even with NI-PoRep, some coordination between the SaaS Provider and Client remains. Indeed during the labeling 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 Provider needs to “wait” for the request (and info) from a client to seal sectors. In other words, this prevents a SaaS Provider from sealing sectors in advance using its HW at max capacity (and therefore reducing sealing cost for everyone). + + +## Specification + + + +1. We add a new type of actor: the Sealer Actor (to be used for SaaS Providers); + 1. This can be a “disposable” actor, no need for an owner key. If something bad happens, create a new id. This is okay because no tokens are locked for this actor; +2. Add the method to create and register `SealerID` + 2. The list of SealerIDs is disjoint from the MinerID list + 3. Add a new map `SealerID -> [SectorNumber]` to the chain state (that is, we have a list of used sector numbers for each sealer); + 1. ie, the actor needs `SectorNumber` facilities. +3. Modify the method `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID` . + 4. Add the `SealerID` field to `SectorNIActivactionInfo` + 2. if empty, use the the minerID + 3. if the sealer id is passed, use it for `ReplicaID` (in the place of miner id) + 4. the method updates the right map of used sector numbers (note that this is needed only if we want to have onchain info about sectors grouped by miner; +4. [Access control, needed to avoid front-run attacks] + 5. 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 the ACL contract. + +![Sealer ID](https://github.com/filecoin-project/FIPs/assets/23217773/4852d5eb-6c81-4fc7-9f7e-dd7a351ed943) + + + + + +## Rationale + +The design aimed to minimize changes with respect to the status quo (in particular, we respect the fact that `ReplicaID` is a unique identifier in the entire Fileocin system) and to provide future programmability. In particular, as regards the access control feature we decide to implement it using a proxy contract (instead of implementing it directly in the actor) in order to have the possibility of the final users (ie, SaaS providers) to personalize it. + + +## Backwards Compatibility + +TODO + + +## Test Cases + +TODO + + +## Security Considerations + +* For the storage providers, this FIP does not add any security risks respect to the status quo; +* For the SaaS provider: in order to have control on who can “activate” (ie, prove commit) their sealed sectors, SaaS providers use the ACL proxy contract. + +## Incentive Considerations + +The proposed change (ie, introducing the sealer id to completely decouple computation-heavy tasks for onboarding sector from the sector ownership) allows SaaS providers to seal sectors 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 + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 15861ed4206baf66e662e26a9ab5515fc32fbcd2 Mon Sep 17 00:00:00 2001 From: Irene <23217773+irenegia@users.noreply.github.com> Date: Tue, 23 Apr 2024 15:10:45 +0200 Subject: [PATCH 02/11] Apply suggestions from code review Co-authored-by: Jiaying Wang <42981373+jennijuju@users.noreply.github.com> --- FIPS/fip-xxx-sealerid.md | 21 ++++----------------- 1 file changed, 4 insertions(+), 17 deletions(-) diff --git a/FIPS/fip-xxx-sealerid.md b/FIPS/fip-xxx-sealerid.md index 42df88a7f..f1c40a01f 100644 --- a/FIPS/fip-xxx-sealerid.md +++ b/FIPS/fip-xxx-sealerid.md @@ -49,39 +49,30 @@ ## Simple Summary Add the notion of `sealerID` and use it 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 `ProveCommitSectorsNI` to seal sectors. ## Abstract -With the current protocol, when a party creates `ReplicaID` needs to use the same `minerID` that will be used for PoRep verifications. This implies that “pre-sealing” sector is not a viable option: no sector can be sealed (ie, replica created) ahead of time, before knowing the identity of the SPs who will own it. To enable this scenario we introduce the concept of `sealerID` to be used in the place of the `minerID` only during sealing. +With the current protocol, the party creates the `ReplicaID` needs to use the same `minerID` that will be used for PoRep verifications. This implies that “pre-sealing” sectors is not a viable option: no sector can be sealed (ie, replica created) ahead of time, before knowing the identity of the miner actor who will own it. To enable this scenario, we introduce the concept of `sealerID` to be used in place of the `minerID` only during sealing. ## Motivation -We consider the scenario where Storage Providers want to delegate some of their activities to external parties in order to let a competition of service providers optimize and lower the costs. +We consider the scenario where Storage Providers want to delegate some of their activities to external parties that offer competitive services at lower costs. In particular, we call **Sealing-as-a-Service (SaaS) Provider** an entity that runs all PoRep operations (labeling the graph, column commitments, MT generation, vanilla proofs and SNARKs generation) needed to get a replica and onboard the sector that contains it. -The SaaS then transfers the replica 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 for storing R and proving validity of the corresponding sector (ie, running window- and winning-PoSt). - - +The SaaS then transfers the replica 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 for storing R and proving validity of the corresponding sector (ie, running window- and winning-PoSt), and/or adding data to the committed capacity sector via SnapDeals. ### Addressed issues: - - 1. [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 [FIP0090](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0090.md) that requires no chain interaction and no deposit. -2. [solved by this FIP] Even with NI-PoRep, some coordination between the SaaS Provider and Client remains. Indeed during the labeling 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 Provider needs to “wait” for the request (and info) from a client to seal sectors. In other words, this prevents a SaaS Provider from sealing sectors in advance using its HW at max capacity (and therefore reducing sealing cost for everyone). +2. [solved by this FIP] Even with NI-PoRep, some coordination between the SaaS Provider and their client (SP) remains. Indeed during the labeling phase the SaaS 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 SaaS Provider needs to “wait” for the request (and info) from a SaaS client to seal sectors. In other words, this prevents a SaaS Provider from sealing sectors in advance using its HW at max capacity (and therefore reducing sealing cost for everyone). ## Specification - - 1. We add a new type of actor: the Sealer Actor (to be used for SaaS Providers); 1. This can be a “disposable” actor, no need for an owner key. If something bad happens, create a new id. This is okay because no tokens are locked for this actor; 2. Add the method to create and register `SealerID` @@ -100,10 +91,6 @@ When an SP onboards a sector (ie, call to method `ProveCommitSectorsNIParams` in ![Sealer ID](https://github.com/filecoin-project/FIPs/assets/23217773/4852d5eb-6c81-4fc7-9f7e-dd7a351ed943) - - - - ## Rationale The design aimed to minimize changes with respect to the status quo (in particular, we respect the fact that `ReplicaID` is a unique identifier in the entire Fileocin system) and to provide future programmability. In particular, as regards the access control feature we decide to implement it using a proxy contract (instead of implementing it directly in the actor) in order to have the possibility of the final users (ie, SaaS providers) to personalize it. From cc6dfb391201107bbfaacd4d92b27d5a94c4f38f Mon Sep 17 00:00:00 2001 From: Irene <23217773+irenegia@users.noreply.github.com> Date: Tue, 23 Apr 2024 15:30:28 +0200 Subject: [PATCH 03/11] Update fip-xxx-sealerid.md --- FIPS/fip-xxx-sealerid.md | 68 ++++++++++++---------------------------- 1 file changed, 20 insertions(+), 48 deletions(-) diff --git a/FIPS/fip-xxx-sealerid.md b/FIPS/fip-xxx-sealerid.md index f1c40a01f..62f3c9eb5 100644 --- a/FIPS/fip-xxx-sealerid.md +++ b/FIPS/fip-xxx-sealerid.md @@ -1,56 +1,27 @@ +--- +fip: "xxx" +title: Introducing sealerID +author: irene (@irenegia), luca (@lucaniz), kuba (@Kubuxu) +discussions-to: https://github.com/filecoin-project/FIPs/discussions/890 +status: Draft +type: Technical +category: Core +dependency: FIP0090 +created: 2023-04-18 +--- -# FIPxxxx: Introducing SealerID - - -## Public doc - - - - - - - - - - - - - - - - - - - - - - - -
fip - title - author - discussion-to - status - type - category - created -
xxxx - Introducing sealerID - kuba (@kubuku), irene (@irenegia), luca (@lucaniz) - https://github.com/filecoin-project/FIPs/discussions/890 - Draft - Technical - Core - 17th April 2024 -
+# FIPxxxx: Introducing sealerID + ## Simple Summary -Add the notion of `sealerID` and use it 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 `ProveCommitSectorsNI` to seal sectors. +Add the notion of `sealerID` and use it for the sealing process of NI-PoRep. In particular: +* We add a new actor, the Sealer Actor so that SealerIDs can be registered; +* `sealerID` can be used to create `ReplicaID` by parting running the SDR labeling algorithm; +* `sealerID` is added to the parameters of the method `ProveCommitSectorsNI`. + ## Abstract @@ -65,10 +36,11 @@ We consider the scenario where Storage Providers want to delegate some of their In particular, we call **Sealing-as-a-Service (SaaS) Provider** an entity that runs all PoRep operations (labeling the graph, column commitments, MT generation, vanilla proofs and SNARKs generation) needed to get a replica and onboard the sector that contains it. The SaaS then transfers the replica 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 for storing R and proving validity of the corresponding sector (ie, running window- and winning-PoSt), and/or adding data to the committed capacity sector via SnapDeals. + ### Addressed issues: 1. [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 [FIP0090](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0090.md) that requires no chain interaction and no deposit. -2. [solved by this FIP] Even with NI-PoRep, some coordination between the SaaS Provider and their client (SP) remains. Indeed during the labeling phase the SaaS 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 SaaS Provider needs to “wait” for the request (and info) from a SaaS client to seal sectors. In other words, this prevents a SaaS Provider from sealing sectors in advance using its HW at max capacity (and therefore reducing sealing cost for everyone). +3. [solved by this FIP] Even with NI-PoRep, some coordination between the SaaS Provider and their client (SP) remains. Indeed during the labeling phase the SaaS 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 SaaS Provider needs to “wait” for the request (and info) from a SaaS client to seal sectors. In other words, this prevents a SaaS Provider from sealing sectors in advance using its HW at max capacity (and therefore reducing sealing cost for everyone). ## Specification From 1b32df0f0dbae01fb0f82b2e39ddeb979138434f Mon Sep 17 00:00:00 2001 From: Irene <23217773+irenegia@users.noreply.github.com> Date: Mon, 29 Apr 2024 10:12:32 +0200 Subject: [PATCH 04/11] Update fip-xxx-sealerid.md --- FIPS/fip-xxx-sealerid.md | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/FIPS/fip-xxx-sealerid.md b/FIPS/fip-xxx-sealerid.md index 62f3c9eb5..967732f25 100644 --- a/FIPS/fip-xxx-sealerid.md +++ b/FIPS/fip-xxx-sealerid.md @@ -1,7 +1,7 @@ --- fip: "xxx" title: Introducing sealerID -author: irene (@irenegia), luca (@lucaniz), kuba (@Kubuxu) +author: nicola (@nicola), irene (@irenegia), luca (@lucaniz), kuba (@Kubuxu) discussions-to: https://github.com/filecoin-project/FIPs/discussions/890 status: Draft type: Technical @@ -12,12 +12,12 @@ created: 2023-04-18 -# FIPxxxx: Introducing sealerID +# FIPXXXX: Introducing sealerID ## Simple Summary -Add the notion of `sealerID` and use it for the sealing process of NI-PoRep. In particular: +This adds the notion of `sealerID`, which is used in the sealing process of NI-PoRep. In particular: * We add a new actor, the Sealer Actor so that SealerIDs can be registered; * `sealerID` can be used to create `ReplicaID` by parting running the SDR labeling algorithm; * `sealerID` is added to the parameters of the method `ProveCommitSectorsNI`. @@ -40,24 +40,24 @@ The SaaS then transfers the replica and the proofs to a **SaaS Client.** This is ### Addressed issues: 1. [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 [FIP0090](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0090.md) that requires no chain interaction and no deposit. -3. [solved by this FIP] Even with NI-PoRep, some coordination between the SaaS Provider and their client (SP) remains. Indeed during the labeling phase the SaaS 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 SaaS Provider needs to “wait” for the request (and info) from a SaaS client to seal sectors. In other words, this prevents a SaaS Provider from sealing sectors in advance using its HW at max capacity (and therefore reducing sealing cost for everyone). +2. [solved by this FIP] Even with NI-PoRep, some coordination between the SaaS Provider and their client (SP) remains. Indeed during the labeling phase the SaaS 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 SaaS Provider needs to “wait” for the request (and info) from a SaaS client to seal sectors. In other words, this prevents a SaaS Provider from sealing sectors in advance using its HW at max capacity (and therefore reducing sealing cost for everyone). ## Specification 1. We add a new type of actor: the Sealer Actor (to be used for SaaS Providers); - 1. This can be a “disposable” actor, no need for an owner key. If something bad happens, create a new id. This is okay because no tokens are locked for this actor; + - This can be a “disposable” actor, no need for an owner key. If something bad happens, create a new id. This is okay because no tokens are locked for this actor; 2. Add the method to create and register `SealerID` - 2. The list of SealerIDs is disjoint from the MinerID list - 3. Add a new map `SealerID -> [SectorNumber]` to the chain state (that is, we have a list of used sector numbers for each sealer); - 1. ie, the actor needs `SectorNumber` facilities. + - 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 needs `SectorNumber` facilities. 3. Modify the method `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID` . - 4. Add the `SealerID` field to `SectorNIActivactionInfo` - 2. if empty, use the the minerID - 3. if the sealer id is passed, use it for `ReplicaID` (in the place of miner id) - 4. the method updates the right map of used sector numbers (note that this is needed only if we want to have onchain info about sectors grouped by miner; + - 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 (note that this is needed only if we want to have onchain info about sectors grouped by miner; 4. [Access control, needed to avoid front-run attacks] - 5. Store in the Sealer Actor another address: this is an address to a proxy contract that can be used to implement ACL + - 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 the ACL contract. @@ -65,7 +65,9 @@ When an SP onboards a sector (ie, call to method `ProveCommitSectorsNIParams` in ## Rationale -The design aimed to minimize changes with respect to the status quo (in particular, we respect the fact that `ReplicaID` is a unique identifier in the entire Fileocin system) and to provide future programmability. In particular, as regards the access control feature we decide to implement it using a proxy contract (instead of implementing it directly in the actor) in order to have the possibility of the final users (ie, SaaS providers) to personalize it. +The design aims to +* Minimize changes with respect to the status quo, particularly maintaining 'ReplicaID' as a unique identifier within the entire Filecoin ecosystem; +* Provide future programmability. In particular, as regards the access control feature we decide to implement it using a proxy contract (instead of implementing it directly in the actor) in order to have the possibility of the final users (ie, SaaS providers) to personalize it. ## Backwards Compatibility @@ -80,7 +82,7 @@ TODO ## Security Considerations -* For the storage providers, this FIP does not add any security risks respect to the status quo; +* For Storage Providers, this FIP does not introduce additional security risks compared to the status quo; * For the SaaS provider: in order to have control on who can “activate” (ie, prove commit) their sealed sectors, SaaS providers use the ACL proxy contract. ## Incentive Considerations From a9b7fcd0eb3feecb709bdffb495d5385f2b2121a Mon Sep 17 00:00:00 2001 From: Irene <23217773+irenegia@users.noreply.github.com> Date: Mon, 29 Apr 2024 14:53:21 +0200 Subject: [PATCH 05/11] Update fip-xxx-sealerid.md added some spec details --- FIPS/fip-xxx-sealerid.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/FIPS/fip-xxx-sealerid.md b/FIPS/fip-xxx-sealerid.md index 967732f25..ac9919b86 100644 --- a/FIPS/fip-xxx-sealerid.md +++ b/FIPS/fip-xxx-sealerid.md @@ -1,6 +1,6 @@ --- fip: "xxx" -title: Introducing sealerID +title: Introducing SealerID author: nicola (@nicola), irene (@irenegia), luca (@lucaniz), kuba (@Kubuxu) discussions-to: https://github.com/filecoin-project/FIPs/discussions/890 status: Draft @@ -45,17 +45,19 @@ The SaaS then transfers the replica and the proofs to a **SaaS Client.** This is ## Specification -1. We add a new type of actor: the Sealer Actor (to be used for SaaS Providers); +1. We add a new type of actor: the Sealer Actor; - This can be a “disposable” actor, no need for an owner key. If something bad happens, create a new id. This is okay because no tokens are locked for this actor; -2. 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 needs `SectorNumber` facilities. -3. 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 (note that this is needed only if we want to have onchain info about sectors grouped by miner; + - The Sealer Actor is multiple instance type: Anyone can create a Sealer Actor and `sealerID` will simply be the actor ID. This ensures that the list of sealerIDs is disjoint from the list of minerIDs. + - The new actor needs `sectorNumber` facilities: There is a map `sealerID -> [sealerSectorNumber]` in the state (that is, we have a list of used sector numbers for each sealer); Concretely this sector number list would be a bitfield as is the case of the miner actor. + +2. Modify the method `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID` . + - Add a new field to `SectorNIActivactionInfo` for passing the sealerID info: + - if empty, use the the minerID when creating the `ReplicaID` + - if a value is passed, use this for `ReplicaID` (in the place of `minerID`) + - Add a new field to `SectorNIActivactionInfo` for passing `sealerSectorNumber`: + - again, if we are in the case EMPTY_SEALER_ID, then `sealerSectorNumber` could either be ignored or enforced to be 0, otherwis eit is used for `ReplicaID`; + - note that the miner actor claims its own sector number in its internal state along side with the sealer's sector number. This means that the structure `{minerID, sectorNumber}` is replaced by `{minerID, sectorNumber, minerSectorNumber}` where last value can be 0. + 4. [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 From 92df9ac6d960b0a96be155a6a90d710aed673499 Mon Sep 17 00:00:00 2001 From: Irene <23217773+irenegia@users.noreply.github.com> Date: Tue, 30 Apr 2024 12:52:08 +0200 Subject: [PATCH 06/11] Update fip-xxx-sealerid.md --- FIPS/fip-xxx-sealerid.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/FIPS/fip-xxx-sealerid.md b/FIPS/fip-xxx-sealerid.md index ac9919b86..ad0a4366f 100644 --- a/FIPS/fip-xxx-sealerid.md +++ b/FIPS/fip-xxx-sealerid.md @@ -57,13 +57,15 @@ The SaaS then transfers the replica and the proofs to a **SaaS Client.** This is - Add a new field to `SectorNIActivactionInfo` for passing `sealerSectorNumber`: - again, if we are in the case EMPTY_SEALER_ID, then `sealerSectorNumber` could either be ignored or enforced to be 0, otherwis eit is used for `ReplicaID`; - note that the miner actor claims its own sector number in its internal state along side with the sealer's sector number. This means that the structure `{minerID, sectorNumber}` is replaced by `{minerID, sectorNumber, minerSectorNumber}` where last value can be 0. + -4. [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 +3. [optional/future] ACL (the sealer has control on who can activate their sealed sectors) + - Option 1: Add a method to the Sealer Actor + add ACL hook; + - TODOs: spec this method + - Option 2: 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, then call to the Sealer Actor. If the ACL is enabled, then call the ACL contract. + - TODOs: write the concrete interface to the ACL contract (eg, `check(sectorNumber, minerID) bool`); write a basic version of an ACL contract and document how to deploy it. ![Sealer ID](https://github.com/filecoin-project/FIPs/assets/23217773/4852d5eb-6c81-4fc7-9f7e-dd7a351ed943) -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 the ACL contract. -![Sealer ID](https://github.com/filecoin-project/FIPs/assets/23217773/4852d5eb-6c81-4fc7-9f7e-dd7a351ed943) ## Rationale @@ -84,8 +86,13 @@ TODO ## Security Considerations -* For Storage Providers, this FIP does not introduce additional security risks compared to the status quo; -* For the SaaS provider: in order to have control on who can “activate” (ie, prove commit) their sealed sectors, SaaS providers use the ACL proxy contract. +* *Front-running Attacks* : + * These are possible also in tyhe current protocol but they are not rational (ie, termination fee will be paid by the front-runner SP); + * If needed, we can implement ACL (see point 3 in the spec) to make this kind of attacks impossible. + +* *Double spending a Sector*: TODO (add a signature done by sealer to make “double-spending” sectors detectable on chain); + + ## Incentive Considerations From 7df574528a15b1a7fdd30a49c75b6f237be89087 Mon Sep 17 00:00:00 2001 From: Irene <23217773+irenegia@users.noreply.github.com> Date: Tue, 30 Apr 2024 15:12:49 +0200 Subject: [PATCH 07/11] Update fip-xxx-sealerid.md --- FIPS/fip-xxx-sealerid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/FIPS/fip-xxx-sealerid.md b/FIPS/fip-xxx-sealerid.md index ad0a4366f..ce780cd61 100644 --- a/FIPS/fip-xxx-sealerid.md +++ b/FIPS/fip-xxx-sealerid.md @@ -63,7 +63,7 @@ The SaaS then transfers the replica and the proofs to a **SaaS Client.** This is - Option 1: Add a method to the Sealer Actor + add ACL hook; - TODOs: spec this method - Option 2: 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, then call to the Sealer Actor. If the ACL is enabled, then call the ACL contract. - - TODOs: write the concrete interface to the ACL contract (eg, `check(sectorNumber, minerID) bool`); write a basic version of an ACL contract and document how to deploy it. ![Sealer ID](https://github.com/filecoin-project/FIPs/assets/23217773/4852d5eb-6c81-4fc7-9f7e-dd7a351ed943) + - TODOs: write the concrete interface to the ACL contract (eg, `check(sectorNumber, minerID) bool`) ![Sealer ID](https://github.com/filecoin-project/FIPs/assets/23217773/4852d5eb-6c81-4fc7-9f7e-dd7a351ed943) @@ -87,7 +87,7 @@ TODO ## Security Considerations * *Front-running Attacks* : - * These are possible also in tyhe current protocol but they are not rational (ie, termination fee will be paid by the front-runner SP); + * These are not rational (ie, termination fee will be paid by the front-runner SP); * If needed, we can implement ACL (see point 3 in the spec) to make this kind of attacks impossible. * *Double spending a Sector*: TODO (add a signature done by sealer to make “double-spending” sectors detectable on chain); From d028a3ccbe800fc9cf7327d38da75c15a5becd20 Mon Sep 17 00:00:00 2001 From: Irene <23217773+irenegia@users.noreply.github.com> Date: Tue, 30 Apr 2024 15:13:36 +0200 Subject: [PATCH 08/11] Update fip-xxx-sealerid.md --- FIPS/fip-xxx-sealerid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-xxx-sealerid.md b/FIPS/fip-xxx-sealerid.md index ce780cd61..ecebf1d6f 100644 --- a/FIPS/fip-xxx-sealerid.md +++ b/FIPS/fip-xxx-sealerid.md @@ -70,7 +70,7 @@ The SaaS then transfers the replica and the proofs to a **SaaS Client.** This is ## Rationale The design aims to -* Minimize changes with respect to the status quo, particularly maintaining 'ReplicaID' as a unique identifier within the entire Filecoin ecosystem; +* Minimize changes with respect to the status quo, particularly maintaining `ReplicaID` as a unique identifier within the entire Filecoin ecosystem; * Provide future programmability. In particular, as regards the access control feature we decide to implement it using a proxy contract (instead of implementing it directly in the actor) in order to have the possibility of the final users (ie, SaaS providers) to personalize it. From 712ff611b8f16e649296e1f29d6555399d0fa481 Mon Sep 17 00:00:00 2001 From: Irene <23217773+irenegia@users.noreply.github.com> Date: Tue, 30 Apr 2024 15:23:51 +0200 Subject: [PATCH 09/11] Update fip-xxx-sealerid.md --- FIPS/fip-xxx-sealerid.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/FIPS/fip-xxx-sealerid.md b/FIPS/fip-xxx-sealerid.md index ecebf1d6f..21ce4b7b2 100644 --- a/FIPS/fip-xxx-sealerid.md +++ b/FIPS/fip-xxx-sealerid.md @@ -60,10 +60,8 @@ The SaaS then transfers the replica and the proofs to a **SaaS Client.** This is 3. [optional/future] ACL (the sealer has control on who can activate their sealed sectors) - - Option 1: Add a method to the Sealer Actor + add ACL hook; - - TODOs: spec this method - - Option 2: 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, then call to the Sealer Actor. If the ACL is enabled, then call the ACL contract. - - TODOs: write the concrete interface to the ACL contract (eg, `check(sectorNumber, minerID) bool`) ![Sealer ID](https://github.com/filecoin-project/FIPs/assets/23217773/4852d5eb-6c81-4fc7-9f7e-dd7a351ed943) + - 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, then call to the Sealer Actor. If the ACL is enabled, then call the ACL contract. + - TODOs: write the concrete interface to the ACL contract (eg, `check(sectorNumber, minerID) bool`) ![Sealer ID](https://github.com/filecoin-project/FIPs/assets/23217773/4852d5eb-6c81-4fc7-9f7e-dd7a351ed943) From 21277caf3442e53896895513d0659f45030c11d4 Mon Sep 17 00:00:00 2001 From: Irene <23217773+irenegia@users.noreply.github.com> Date: Mon, 13 May 2024 11:53:43 +0200 Subject: [PATCH 10/11] Apply suggestions from code review Co-authored-by: Rod Vagg --- FIPS/fip-xxx-sealerid.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/FIPS/fip-xxx-sealerid.md b/FIPS/fip-xxx-sealerid.md index 21ce4b7b2..cd92c274d 100644 --- a/FIPS/fip-xxx-sealerid.md +++ b/FIPS/fip-xxx-sealerid.md @@ -26,7 +26,7 @@ This adds the notion of `sealerID`, which is used in the sealing process of NI-P ## Abstract -With the current protocol, the party creates the `ReplicaID` needs to use the same `minerID` that will be used for PoRep verifications. This implies that “pre-sealing” sectors is not a viable option: no sector can be sealed (ie, replica created) ahead of time, before knowing the identity of the miner actor who will own it. To enable this scenario, we introduce the concept of `sealerID` to be used in place of the `minerID` only during sealing. +With the current protocol, the party that creates the `ReplicaID` needs to use the same `minerID` that will be used for PoRep verifications. This implies that “pre-sealing” sectors is not a viable option: no sector can be sealed (ie, replica created) ahead of time, before knowing the identity of the miner actor who will own it. To enable this scenario, we introduce the concept of `sealerID` to be used in place of the `minerID` only during sealing. ## Motivation @@ -37,24 +37,24 @@ In particular, we call **Sealing-as-a-Service (SaaS) Provider** an entity that r The SaaS then transfers the replica 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 for storing R and proving validity of the corresponding sector (ie, running window- and winning-PoSt), and/or adding data to the committed capacity sector via SnapDeals. -### Addressed issues: +### Addressed issues 1. [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 [FIP0090](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0090.md) that requires no chain interaction and no deposit. -2. [solved by this FIP] Even with NI-PoRep, some coordination between the SaaS Provider and their client (SP) remains. Indeed during the labeling phase the SaaS 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 SaaS Provider needs to “wait” for the request (and info) from a SaaS client to seal sectors. In other words, this prevents a SaaS Provider from sealing sectors in advance using its HW at max capacity (and therefore reducing sealing cost for everyone). +2. [solved by this FIP] Even with NI-PoRep, some coordination between the SaaS Provider and their client (SP) remains. Indeed during the labelling phase the SaaS Provider creates `ReplicaID` and for this it 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 SaaS Provider needs to “wait” for the request (and info) from a SaaS client to seal sectors. In other words, this prevents a SaaS Provider from sealing sectors in advance using its HW at max capacity (and therefore reducing sealing cost for everyone). ## Specification 1. We add a new type of actor: the Sealer Actor; - This can be a “disposable” actor, no need for an owner key. If something bad happens, create a new id. This is okay because no tokens are locked for this actor; - - The Sealer Actor is multiple instance type: Anyone can create a Sealer Actor and `sealerID` will simply be the actor ID. This ensures that the list of sealerIDs is disjoint from the list of minerIDs. + - The Sealer Actor is a multiple instance type: Anyone can create a Sealer Actor and `sealerID` will simply be the actor ID. This ensures that the list of sealerIDs is disjoint from the list of minerIDs. - The new actor needs `sectorNumber` facilities: There is a map `sealerID -> [sealerSectorNumber]` in the state (that is, we have a list of used sector numbers for each sealer); Concretely this sector number list would be a bitfield as is the case of the miner actor. 2. Modify the method `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID` . - Add a new field to `SectorNIActivactionInfo` for passing the sealerID info: - if empty, use the the minerID when creating the `ReplicaID` - if a value is passed, use this for `ReplicaID` (in the place of `minerID`) - - Add a new field to `SectorNIActivactionInfo` for passing `sealerSectorNumber`: + - Add a new field to `SectorNIActivationInfo` for passing `SealerSectorNumber`: - again, if we are in the case EMPTY_SEALER_ID, then `sealerSectorNumber` could either be ignored or enforced to be 0, otherwis eit is used for `ReplicaID`; - note that the miner actor claims its own sector number in its internal state along side with the sealer's sector number. This means that the structure `{minerID, sectorNumber}` is replaced by `{minerID, sectorNumber, minerSectorNumber}` where last value can be 0. From 5c813ce4d2c4dae5a1f9ba76d9647e9f732323c4 Mon Sep 17 00:00:00 2001 From: Irene <23217773+irenegia@users.noreply.github.com> Date: Wed, 22 May 2024 17:13:18 +0200 Subject: [PATCH 11/11] Apply suggestions from code review Co-authored-by: Rod Vagg --- FIPS/fip-xxx-sealerid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/FIPS/fip-xxx-sealerid.md b/FIPS/fip-xxx-sealerid.md index cd92c274d..861197436 100644 --- a/FIPS/fip-xxx-sealerid.md +++ b/FIPS/fip-xxx-sealerid.md @@ -51,12 +51,12 @@ The SaaS then transfers the replica and the proofs to a **SaaS Client.** This is - The new actor needs `sectorNumber` facilities: There is a map `sealerID -> [sealerSectorNumber]` in the state (that is, we have a list of used sector numbers for each sealer); Concretely this sector number list would be a bitfield as is the case of the miner actor. 2. Modify the method `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID` . - - Add a new field to `SectorNIActivactionInfo` for passing the sealerID info: + - Add a new field to `SectorNIActivationInfo` for passing the `SealerID`: - if empty, use the the minerID when creating the `ReplicaID` - if a value is passed, use this for `ReplicaID` (in the place of `minerID`) - Add a new field to `SectorNIActivationInfo` for passing `SealerSectorNumber`: - again, if we are in the case EMPTY_SEALER_ID, then `sealerSectorNumber` could either be ignored or enforced to be 0, otherwis eit is used for `ReplicaID`; - - note that the miner actor claims its own sector number in its internal state along side with the sealer's sector number. This means that the structure `{minerID, sectorNumber}` is replaced by `{minerID, sectorNumber, minerSectorNumber}` where last value can be 0. + - note that the miner actor identifies sectors internally using a `SectorID` structure with a `{minerID, sectorNumber}` pair. This is replaced by `{minerID, sectorNumber, minerSectorNumber}` where last value can be 0. 3. [optional/future] ACL (the sealer has control on who can activate their sealed sectors)