Skip to content

FIPXXXX: Introducing sealerID #993

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 11 commits into
base: master
Choose a base branch
from
+112 −0
Draft

FIPXXXX: Introducing sealerID #993

Changes from 3 commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
2b95255
Create fip-xxx-sealerid.md
irenegia Apr 17, 2024
15861ed
Apply suggestions from code review
irenegia Apr 23, 2024
cc6dfb3
Update fip-xxx-sealerid.md
irenegia Apr 23, 2024
1b32df0
Update fip-xxx-sealerid.md
irenegia Apr 29, 2024
a9b7fcd
Update fip-xxx-sealerid.md
irenegia Apr 29, 2024
92df9ac
Update fip-xxx-sealerid.md
irenegia Apr 30, 2024
7df5745
Update fip-xxx-sealerid.md
irenegia Apr 30, 2024
d028a3c
Update fip-xxx-sealerid.md
irenegia Apr 30, 2024
712ff61
Update fip-xxx-sealerid.md
irenegia Apr 30, 2024
21277ca
Apply suggestions from code review
irenegia May 13, 2024
5c813ce
Apply suggestions from code review
irenegia May 22, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
103 changes: 103 additions & 0 deletions FIPS/fip-xxx-sealerid.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,103 @@
---
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


## Simple Summary

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

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 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), 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.
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

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand it the SealerActor type should be a multiple instance type. Anyone can create a SealerActor and SealerID will simply be the actor ID. This ensures SealerIDs are disjoin from MinerIDs. If we wanted a singleton actor it would become quite difficult to ensure they are disjoint.

Copy link
Contributor Author

@irenegia irenegia Apr 29, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, no singleton actor. We should go with the two separate actors. I'll update the spec with the details you suggested here 🙏 .

3. Add a new map `SealerID -> [SectorNumber]` to the chain state (that is, we have a list of used sector numbers for each sealer);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concretely this sector number list would be a bitfield as is the case in the miner actor.

1. ie, the actor needs `SectorNumber` facilities.
3. Modify the method `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID` .
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If NI PoRep were accepted and shipped in an upgrade first, we will need to add a new method, ProveCommitSectorsNI2, for this change, given this is a breaking change.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this "fully enables" NI-Porep, does this make it worth considering folding this into that FIP?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However we organize the FIPS I think it would be ideal to land both at the same time

Copy link
Contributor Author

@irenegia irenegia Apr 29, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ZenGround0 we are planning to ship NI-PoRep in nv23, but I don't think sealearID can make for it, unless we prioritise it now (fine with me)... what's your opinion on this?

cc @rjan90

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I would prefer we ship them together so we can maintain the momentum from NI Porep and immediately unlock sealing as a service. But I don't know if filoz has the capacity to get both done on time.

4. Add the `SealerID` field to `SectorNIActivactionInfo`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note we'll also need to add SealerSectorNumber to the activation info as this will generally need to be separately declared from the miner actor's sector number.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use CBOR -1 or some well defined value <= current actor id to indicate EMPTY_SEALER_ID. SealerSectorNumber could either be ignored or enforced to be 0 if we have the EMPTY_SEALER_ID case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or alternatively we could enforce SealerID is explicitly set as minerID in the empty case.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these are disjoint sets, your recent post would make the proposal simpler to code and verify: struct{sealerID, sectorNumber} would be a unique identifier, replacing struct{minerID, sectorNumber}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 I agree with {sealerID, sectorNumber} for replica ID info. Annoyingly replica ID sector number and miner metadata sectorNumber will be different so we do have to handle that. Probably with {minerID, sectorNumber, minerSectorNumber} where last value can be -1.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the plan to ship an FRC for this hook/interface as well..?


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An idea from @jennijuju: One design direction to consider is making the SealerActor an Fevm actor. We could do this by writing a user contract that enforces sector numbers are only claimed once. Then when calling sealer id from miner actor we check that we are 1) calling evm actor 2) the bytecode of the evm actor matches the expected contract.

Reasons for and against are pretty split so I don't know which to advocate for.

Reasons FOR

  • Take advantage of solidity development tooling
  • Less actor bundle overhead
  • No migration overhead
  • We can deploy and test out the contract before the upgrade

Reasons AGAINST

  • Performance might suffer
  • Probably a bit harder to develop for our team. Less copy past of rust code, more learning new stuff. Not in builtin actors repository. Miss out on builtin actors testing framework.
  • Finding/building a performant analogue to the bitfield data type in solidity might be too much

@anorth @Kubuxu @Stebalien any thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved design question to #890 (comment) so it’s more discoverable and trackable

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seems to me that the conclusion here is to go with the original proposed design (sealer id in actor code and all other feature, as for example the ACL, in FEVM)
#890 (reply in thread)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@magik6k @snadrus what's your take on this proposal?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sketch of this spec looks fine, but it's missing a lot of detail at the moment.

  • The sealer actor's state schema should be specified (fairly simple, but at least leave room for an owner later on)
  • The sealer actor will need a method that checks and consumes sector numbers, called from the miner actor.
  • If we want the ACL features now, the API for it needs to be specified here. Or just cut it from scope now.

![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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been looking into the use of prover_id and sector_number by the window post circuit. I think that these values do not need to match the prover_id and sector_number used by sealing as they are used for challenge generation independent of the sealing process.

However if these values do need to be the same across sealing and post we will have to change miner actor state to keep around enough information to reconstruct the sealer id and sector number.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any other instances where we need the inputs to the ReplicaID (original sector number and prover id) after commiting a sector? Are there any reasons we might want these in the future? If so it is important to identify them so we can make sure we have enough information in the miner actor state.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been looking into the use of prover_id and sector_number by the window post circuit. I think that these values do not need to match the prover_id and sector_number used by sealing as they are used for challenge generation independent of the sealing process

Correct, they do not need to match.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any other instances where we need the inputs to the ReplicaID (original sector number and prover id) after commiting a sector?

@lucaniz and I checked for this, we did not find any

Are there any reasons we might want these in the future?

Nothing that come to mind to me now :)

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/).