Introduce SealerID for a real trustless delegation of onboarding tasks

[lucaniz]

Background

Non Interactive PoRep aims to remove PCD and unblocks trustless delegation of sector onboarding tasks (sealing and proving). Moreover, all the different onboarding step could be in principle outsourced to external parties in a trustless manner.

In this new world, SPs delegate some of their activities to external parties in order to let a competition of service providers optimize and lower the costs. For example, sealing and proving could be delegated to external Sealing-as-a-Service and SNARK provers that have better streamlined pipelines.

Nevertheless, NI-PoRep alone is not sufficient for this trustless delegation to happen in practice.

Motivation

Currently the protocol does not allow for trustless delegation of sealing and proving, as both the steps are related to the SP ID (often referred as MinerID).

We should explicitly separate the SP ID (often referred to as MinerID) from the SealerID. For simplicity, we assume SealerID is an entity which both seals and proves sectors (i.e. labelling and snarks, eventually splitting tasks internally).

Decoupling sector sealing and proving and sector ownership would allow to create a market for inactive CC sectors: Saas Providers could be seamlessly generating CC sectors and sell them to other Storage Providers without the risk of losing collateral, and without the need to know in advance who is going to be the sector owner.

Note that this is particularly relevant as we want to unlock the SaaS/CC sector market use case, as there would be no need to know “sealing requests” in advance.

Indeed, in the current scenario we’d have the following flow:

• SP who want to seal new sector share MinerID with SaaS provider
• SaaS provider seals sectors on demand

This flow is inefficient by definition as it needs continuous demand in order to be optimized

If we decouple SealerID and MinerID, the flow would be optimized:

• SaaS provider seals sectors at full throughput
• SaaS provider sell pre-sealed sectors on demand

Proposal

Add the notion of SealerID and use if for the sealing process instead of the MinerID. We need to:

• Allow for SealerIDs to be registered
• Change the MinerID used for the sealing process to be the SealerID
• Change the MinerActor to allow for any sector from any SealerID to be added into the protocol (if not used).

[anorth]

Conceptually 👍 , this will be great. There are some implementation details to work out though.

I understand that the SealerID is primarily use to provide uniqueness of a seal proof and hence physical sector. The (SealerID, SectorNumber) tuple must be globally unique. It is today with SealerID == MinerID because the miner actor maintains a collection of sectors IDs and prevents re-use. We'll need something similar for non-miner sealers. Naively this means some new chain state with a mapping from SealerID (disjoint from Miner IDs) to a collection of used Sector Numbers for each sealer. At PoRep time, the SP must submit the sealer ID used for each sector and the chain must check and update the collection of used sector numbers for that sealer. It sounds like this will require a new actor. There is also some complication about masking out ranges of used sectors to ensure a compact bitfield representation, and so access rules about who can do that, etc.

Is there any necessary relationship between the SealerID used at PoRep and the ProverID used in Window PoST? Will a miner that receives a pre-sealed sector then be able to use their own miner ID as the ProverID for WindowPoST, or will we need to remember somewhere each sector's SealerID?

[lucaniz]

Great points.

Is there any necessary relationship between the SealerID used at PoRep and the ProverID used in Window PoST? Will a miner that receives a pre-sealed sector then be able to use their own miner ID as the ProverID for WindowPoST, or will we need to remember somewhere each sector's SealerID?

Ideally a SP should be able to use his own minerID as the ProverID for WindowPoST, even if we should double check in the pre-FIP research/analysis stage if this is fine security wise (I think so, I guess we'd need to check that this sector has not been proven with windowpost by another ID before)

[suykerbuyk]

I want to validate my perceptions of what this might enable, particularly with NiPoREP.

CC sectors can be generated in mass, and thanks to NiPoREP, commits on the chain can be delayed until later. This FIP would enable the transfer of ownership of a CC sector without revealing any of the underlying private key data of either the originator or the consumer of the miner.

In theory, this would allow the transfer of ownership of sectors, sealed or unsealed, between various service providers via smart contracts rather than shared wallets.

If I am somewhat accurate, I believe this would also enable relatively graceful scaling, up and down of an individual storage provider capacity in response to both market demand and provider circumstances. It also seems that this would finally enable a truly "generic" sealing as a service for both offline and online operations at relatively large scales.

[lucaniz]

@suykerbuyk basically what we want enable with this is the possibility of sealing a sector without the need of MinerID. This would allow for a pre-sealed sector market in which the sealer entity seals a set of sectors whose ownership can be transferred later on by associating the sector sealed by a SealerID to a MinerID.
Did I clarify your point`?

[irenegia]

FYI @suykerbuyk
the draft of the FIP is here #993

[jennijuju]

Starting a thread fo the Sealer Actor, which is currently proposed as a new, dedicated actor type.

It is not too clear to me whether
Is this a skeleton actor with only a constructor, like an account actor? If so, can we use something other than the existing account actor type for this?

• or is this an actor who holds a list of sealer IDs, like a registry?

Taking from the FIP,

This can be a “disposable” actor, no need for an owner key. If something bad happens, create a new id

It seems like we can use any of the existing account types for SealerID—private key-backed wallets, f4s, f2, or anything else. (which all can be treated as unique identifiers on the chain, in the protocol, maybe we should just store the ID address always.

@ZenGround0 / @Kubuxu wdyt?

[irenegia]

(2) Is SaaS provider required to get a sector number from SaaS client, register it onchain before presealing?

no (see my answer above, in this proposed design, sealerID has its own list)

[jennijuju]

We need the registry functionality, like each sealerID has its own list of sector numbers. This is because we want that replicaID (which is Hash(ownerID, sectornNumer)) is unique in the whole Filecoin system. So each time that you do NI-ProveCommit with the sealerID as owner, you need to use a new unused sector number.

I see - so the map you are storing is sealID - minerID - sector number.
How does the sealer get the sector number, does the SP send it to them?

[lucaniz]

No, in the current design Sealer has his own counter for Sector Number (i.e. its own list)

[jennijuju]

@lucaniz How does Sealer Sec Num relate to Miner Sec Num, or are they not related at all? Basically whats the goal of keeping this sealer sector number?

[Kubuxu]

The way I think about it is that there is a SealerActor that holds a bitfield of used-up SectorIDs. These SectorIDs are relevant only for PoRep; during the sector onboarding, the SP can assign their own SectorID, which will serve as a global sector identifier (in the form of (MinerID, SectorID')) and will be used from then on. Sealer's SectorID becomes irrelevant after onboarding the sector with one caveat, so the tuple of (SealerID, SectorID) must not be used to generate another replica.

We also should generate an event when the sector is onboarded to have a persistent receipt of which (SealerID, SectorID) tuple was used to generate the given replica. This information can be later used for recovery scenarios or third-party unsealing.

[jennijuju]

Move @ZenGround0 ’s comment from #993 (comment)

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?

[ZenGround0]

So the question I have is: is a sealer ID registry something the filecoin l1 absolutely needed?

After thinking about this more it is essential that the code for the sealer actor is agreed upon by the core protocol. The reason is that sector numbers per sealer actor must be unique to guarantee unique sector keys.

The questions that remain are how much protocol development we want to push to fevm. It looks like the answer is: most of it but it depends on if we want to.

[ZenGround0]

What’s use case of it ? Who’s the user of it?

My understanding is that the users of this new part of the system are

1. Sealing as a Service providers who create a sealer actor and maybe set up ACL
2. SPs consuming sealing as a service who call this actor through prove commit so the chain can verify their PoReps

[anorth]

If it has to be trusted by the network (which sealer ID does) then it should be a built-in actor. Asserting a specific EVM bytecode is just a really indirect way of specifying exactly the code we want, but one that introduces a much larger surface to be trusted and conceptual friction for the maintainers.

There is room for a permissioning / ACL / payment actor which could be user-programmed and thus support FEVM (for now). @Kubuxu has explained this design for me but I don't know where it's written up.

[irenegia]

There is room for a permissioning / ACL / payment actor which could be user-programmed and thus support FEVM (for now). @Kubuxu has explained this design for me but I don't know where it's written up.

The idea of ACL via FEVM contract is sketched in the specification section of the fip #993 , but i would like devs help to add more code details (if needed)

[ZenGround0]

Asserting a specific EVM bytecode is just a really indirect way of specifying exactly the code we want

Yes

but one that introduces a much larger surface to be trusted and conceptual friction for the maintainers.

For now but I'm not sure how this looks in the future. It's probably easier to onboard a new protocol engineer with experience writing smart contracts to FeVM for example. In any case looks like for this one its too early.

[steven004]

This proposal seems promising. Here, it appears that the SectorID could function similarly to the current combination of minerID and sectorNumber. We might simplify this by implementing a globally unique sectorNumber. Although I haven't fully thought this through, the process could potentially unfold step by step as follows:

1. Implement Global Uniqueness of SectorNumber:
   This is an initial step towards removing the minerID from the proving process. We could allocate a range of globally unique sectorNumbers to each newly created miner (or even existing miners) to simplify this. When default-assigned numbers are exhausted, a miner would need to apply for an additional range.

2. Removal of MinerID from Proving:
   Once each sectorNumber is globally unique, removing the minerID from the proving process should be straightforward.

3. Sector Ownership Binding and Transferability:
   A sector must be owned by a miner; this allows us to calculate the miner’s power, or do slashing if proof is not submitted on time. With the removal of the minerID from the sector's state, but maintaining a binding map to reflect ownership, the transferability of sectors is naturally supported.

[snadrus]

This FIP should include a way to add a chain message that binds an upcoming sector's ID's activation to a given smart contract. This enables the seller to dictate the terms (price, activate-must-succeed, acl?) and the buyer to see this in-the-clear. The only requirement of the chain is that the activation call happens from the specified Smart Contract.