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

	- Add a new field to `SectorNIActivactionInfo` for passing the sealerID info:
	- Add a new field to `SectorNIActivationInfo` for passing the `SealerID`:

[rvagg]

I see that FIP-0090 already has a SealerID in it, but it's not nullable / Option, is there some reconciliation that needs to happen between the two?

[irenegia]

@ZenGround0 could you help here please?

[ZenGround0]

Let's not allow these to be nullable. FIP 0090 needs to assert some constraints (SealerID == ActorID) but once the sealer actor shows up we won't need any constraints, we'll just check whatever actor is at SealerID for unused SealingNumber. If we don't rely on an external SealingActor the caller can set SealerID to ActorID

[rvagg]

Suggested change

	- if empty, use the the minerID when creating the `ReplicaID`
	- if null, use the the minerID when creating the `ReplicaID`

alternatively 0?

[rvagg]

introducing new terminology, maybe just keep it simple?

Suggested change

	- 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`;
	- again, if `SealerID` is null, then `SealerSectorNumber` could either be ignored or enforced to be 0, otherwise it is used for `SectorNumber`;

[rvagg]

I might be parsing this wrong, but I think the word "state" here might be misplaced, or suggesting something that it shouldn't? I think this might be referring to the internal way that the actor identifies a sector, via the SectorID compound structure: https://github.com/filecoin-project/ref-fvm/blob/31118cfad2e83dc3f6202f38ce7d96cd1c747aea/shared/src/sector/mod.rs#L54-L59

Suggested change

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

Does that sound right?