FIPXXXX: Introducing sealerID

[irenegia]

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

[jennijuju]

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.

[snadrus]

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

[ZenGround0]

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

[irenegia]

@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

[ZenGround0]

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.

[jennijuju]

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

[jennijuju]

Editor: I think we will need a bit more spec design work to do before it can be merged😄 would recommend to turn this FIP into a draft PR until them

[ZenGround0]

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.

[irenegia]

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

[ZenGround0]

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

[ZenGround0]

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.

[ZenGround0]

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.

[ZenGround0]

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

[snadrus]

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}

[ZenGround0]

👍 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.

[ZenGround0]

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?

[jennijuju]

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

[irenegia]

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)

[ZenGround0]

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.

[ZenGround0]

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.

[irenegia]

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.

[irenegia]

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 :)

[rvagg]

Suggested change

	2. Modify the method `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID` .
	- 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 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.
	2. Modify the handling of parameters to `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID`:
	- Allow the `SealerID` field in `SectorNIActivationInfo` to specify an actor separate to the calling actor and use this for `ReplicaID` (i.e. it will either be the actor ID of the storage provider, or the actor ID of the sealer in the case of involvement of a sealing SaaS).
	- Allow the `SealingNumber` field of `SectorNIActivationInfo` to accept a sector number different to the number allocated in the calling actor's state for this sector and use this for `ReplicaID`.
	- note that the miner actor identifies sectors internally using a `SectorID` structure with a `{minerID, sectorNumber}` pair. This is replaced by `{minerID, sectorNumber, sealerSectorNumber}` where 2nd and 3rd values may be the same.

So does this get us closer to the diff on top of 0090 @irenegia @ZenGround0 ?

[anorth]

Suggested change

	1. We add a new type of actor: the Sealer Actor;
	1. We add a new type of built-in actor: the Sealer Actor;

Suggested change

	1. We add a new type of actor: the Sealer Actor;
	1. We add a new type of actor: the Sealer Actor;

[anorth]

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.